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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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The present document specifies the security architecture, i.e., the security features and the security mechanisms for the 
Evolved Packet System and the Evolved Packet Core, and the security procedures performed within the evolved Packet 
System (EPS) including the Evolved Packet Core (EPC) and the Evolved UTRAN (E-UTRAN). 
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[21] 3GPP TS 36.33 l:"Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control 

(RRC); Protocol specification". 
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[24] 3GPP TS 25.331: "3rd Generation Partnership Project; Technical Specification Group Radio 

Access Network; Radio Resource Control (RRC); Protocol Specification ". 
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GSM/EDGE Radio Access Network; General Packet Radio Service (GPRS); Mobile Station (MS) 
- Base Station System (BSS) interface; Radio Link Control/Medium Access Control (RLC/MAC) 
protocol 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1], in TS 33.102 [4] and the 
following apply. A term defined in the present document takes precedence over the definition of the same term, if any, 
in TR 21.905 [1]. 

Access Security Management Entity: entity which receives the top-level keys in an access network from the HSS. For 
E-UTRAN access networks, the role of the ASME is assumed by the MME 

Activation of security context: the process of taking into use a security context. 

Authentication data: Data that is part of a security context or of authentication vectors. 

Chaining of Kcnb: derivation of a new KeNB from another Ksnb (ie-, at cell handover) 

Current EPS security context: The security context which has been activated most recently. Note that a current EPS 
security context originating from either a mapped or native EPS security context may exist simultaneously with a native 
non-current EPS security context. 

ECM-CONNECTED state: This is as defined in TS 23.401 [2]. The term ECM-CONNECTED state corresponds to 
the term EMM-CONNECTED mode used in TS 24.301 [9]. 

ECM-IDLE state: As defined in TS 23.401 [2]. The term ECM-IDLE state corresponds to the term EMM-IDLE mode 
used in TS 24.301 [9]. 

EPS-Authentication Vector: Kasme, RAND, AUTN, XRES 

EPS security context: A state that is established locally at the UE and a serving network domain. At both ends "EPS 
security context data" is stored, that consists of the EPS NAS security context, and the EPS AS security context. 

NOTE 1: An EPS security context has type 'mapped', 'full native' or 'partial native'. Its state can either be 'current' or 
'non-current'. A context can be of one type only and be in one state at a time. The state of a particular 
context type can change over time. A partial native context can be transformed into a full native. No other 
type transformations are possible. 

EPS AS security context: the cryptographic keys at AS level with their identifiers, the Next Hop parameter NH, the 
Next Hop Chaining Counter parameter NCC used for next hop access key derivation, the identifiers of the selected AS 
level cryptographic algorithms and counters used for replay protection. Note that the EPS AS security context only 
exists when the UE is in ECM-CONNECTED state and is otherwise void. 



£75/ 



3GPP TS 33.401 version 8.4.0 Release 8 10 ETSI TS 133 401 V8.4.0 (2009-07) 

NOTE: NH and NCC need to be stored also at the MME during connected mode. 

EPS NAS security context: This context consists of Kasme with the associated key set identifier the UE security 
capabiHties, and the upHnk and downhnk NAS COUNT values. In particular, separate pairs of NAS COUNT values are 
used for each EPS NAS security contexts, respectively. The distinction between native and mapped EPS security 
contexts also applies to EPS NAS security contexts. The EPS NAS security context is called Tull' if it additionally 
contains the keys KNASim and Knascmc and the identifiers of the selected NAS integrity and encryption algorithms. 

Full native EPS security context: A native EPS security context for which the EPS NAS security context is full 
according to the above definition. A full native EPS context is either in state 'current' or state 'non-current'. 

Forward security: In the context of KgNB key derivation, forward security refers to the property that, for an eNB with 
knowledge of a KeNB, shared with a UE, it shall be computationally infeasible to predict any future Kcnb, that will be 
used between the same UE and another eNB. More specifically, n hop forward security refers to the property that an 
eNB is unable to compute keys that will be used between a UE and another eNB to which the UE is connected after n or 
more handovers (n=l or 2). 

Legacy security context: A security context which has been established according to TS 33.102 [4]. 

Mapped security context: Security context created by converting the current security context in the source system to a 
security context for the target system in inter-system mobility, e.g., UMTS keys created from EPS keys. The EPS NAS 
security context of a mapped security context is full. 

Native EPS security context: An EPS security context whose Kasme was created by a run of EPS AKA. 

Non-current EPS security context: A native EPS security context that is not the current one. A non-current EPS 
security context may be stored along with a current EPS security context in the UE and the MME. A non-current EPS 
security context does not contain an EPS AS security context. A non-current EPS security context is either of type 'full 
native' or of type 'partial native'. 

Partial native EPS security context: A partial native EPS security context consists of Kasme with the associated key 
set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values, which are initially set to 
zero. A partial native EPS security context is created by an EPS AKA, for which no corresponding successful NAS 
SMC has been run. A partial native context is always in state 'non-current'. 

Re-derivation of NAS keys: derivation of new NAS keys from the same Kasme but including different algorithms (and 
no freshness parameter) 

Refresh of KeNB^ derivation of a new K^nb from the same Kasme and including a freshness parameter 

Re-keying of KeNB* derivation of a new K^nb from a new Kasme (ie., after an AKA has taken place) 

Re-keying of NAS keys: derivation of new NAS keys from a new Kasme 

UE security capabilities: The set of identifiers corresponding to the ciphering and integrity algorithms implemented in 
the UE. This includes capabilities for EPS AS and NAS, and includes capabilities for UTRAN and GERAN if these 
access types are supported by the UE. 

UE EPS security capabilities: The UE security capabilities for EPS AS and NAS. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 
II Concatenation 

© Bitwise Exclusive Or (XOR) operation 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 
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AES Advanced Encryption Standard 

AK Anonymity Key 

AKA Authentication and Key Agreement 

AMF Authentication Management Field 

AN Access Network 

AS Access Stratum 

AUTN Authentication token 

AV Authentication Vector 

ASME Access Security Management Entity 

Cell-ID Cellldentity as used in TS 36.331 [21] 

CK Cipher Key 

CKSN Cipher Key Sequence Number 

C-RNTI Cell RNTl as used in TS 36.331 [21] 

DoS Denial of Service 

EARFCN-DL E-UTRA Absolute Radio Frequency Channel Number-Down Link 

ECM EPS Connection Management 

EEA EPS Encryption Algorithm 

EIA EPS Integrity Algorithm 

eKSI Key Set Identifier in E-UTRAN 

EMM EPS Mobility Management 

eNB Evolved Node-B 

EPC Evolved Packet Core 

EPS Evolved Packet System 

EPS-AV EPS authentication vector 

E-UTRAN Evolved UTRAN 

GERAN GSM EDGE Radio Access Network 

GUTI Globally Unique Temporary Identity 

HE Home Environment 

HFN Hyper Frame Number 

HO Hand Over 

HSS Home Subscriber Server 

IK Integrity Key 

IKE Internet Key Exchange 

IMEI International Mobile Equiptment Identity 

IMEI(SV) IMEI (Software Version) 

IMSI International Mobile Subscriber Identity 

IRAT Inter-Radio Access Technology 

ISR Idle Mode Signaling Reduction 

KDF Key Derivation Function 

KSI Key Set Identifier 

LSB Least Significant Bit 

LSM Limited Service Mode 

MAC-I Message Authentication Code for Integrity (terminology of TS36.323 [12]) 

MACT Message Authentication Code T used in AES CMAC calculation 

ME Mobile Equipment 

MME Mobility Management Entity 

MS Mobile Station 

MSC Mobile Switching Center 

MSIN Mobile Station Identification Number 

NAS Non Access Stratum 

NAS-MAC Message Authentication Code for NAS for Integrity (called MAC in TS24.301 [9]) 

NCC Next hop Chaining Counter 

NH Next Hop 

PCI PhysicalCellldentity as used in TS 36.331 [21] 

PLMN PubUc Land Mobile Network 

PRNG Pseudo Random Number Generator 

P-TMSI Packet- Temporary Mobile Subscriber Identity 

PDCP Packet Data Convergence Protocol 

RAND RANDom number 

RAU Routing Area Update 

RRC Radio Resource Control 

SGSN Serving GPRS Support Node 
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SIM Subscriber Identity Module 

SMC Security Mode Command 

SN Serving Network 

SN id Serving Network identity 

SQN Sequence Number 

SRB Source Route Bridge 

SRVCC Single Radio Voice Call Continuity 

S-TMSI S-Temporary Mobile Subscriber Identity 

TAI Tracking Area Identity 

TAU Tracking Area Update 

UE User Equipment 

UEA UMTS Encryption Algorithm 

UIA UMTS Integrity Algorithm 

UICC Universal Integrated Circuit Card 

UMTS Universal Mobile Telecommunication System 

UP User Plane 

USIM Universal Subscriber Identity Module 

UTRAN Universal Terrestrial Radio Access Network 

XRES Expected Response USIM 

3.4 Conventions 

All data variables in the present document are presented with the most significant substring on the left hand side and the 
least significant substring on the right hand side. A substring may be a bit, byte or other arbitrary length bitstring. 
Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0, 
the next most significant is numbered 1, and so on through to the least significant. 



4 Overview of Security Architecture 

Figure 4-1 gives an overview of the complete security architecture. 
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Figure 4-1 : Overview of the security architecture 

Five security feature groups are defined. Each of these feature groups meets certain threats and accomplishes certain 
security objectives: 

Network access security (I): the set of security features that provide users with secure access to services, and 
which in particular protect against attacks on the (radio) access link. 
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Network domain security (II): the set of security features that enable nodes to securely exchange signalling 
data, user data (between AN and SN and within AN), and protect against attacks on the wireline network. 

User domain security (III): the set of security features that secure access to mobile stations. 

Application domain security (IV): the set of security features that enable applications in the user and in the 
provider domain to securely exchange messages. 

Visibility and configurability of security (V): the set of features that enables the user to inform himself 
whether a security feature is in operation or not and whether the use and provision of services should depend on 
the security feature. 
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5 Security Features 

5.1 User-to-Network security 



5.1 .1 User identity and device confidentiality 

User identity confidentiality is as defined by TS 33.102 [4] subclause 5.1.1 

From subscriber's privacy point of view, the MSIN (also IMEI) should be confidentiality protected. 

The UE shall provide its equipment identifier IMEI(SV) to the network, if the network asks for it. 

The IMEI shall be securely stored in the terminal. 

The UE shall not send IMEI(SV) to the network on a network request before the NAS security has been activated. 

The IMEI(SV) shall be sent in the NAS protocol. 

NOTE: In some cases, e.g., the very first attach procedure, MSIN has to be sent to network in cleartext. When NAS 
confidentiality protection is beyond an operator option, IMEI (SV) can not be confidentiality protected. 

5.1 .2 Entity autlnentication 

Entity authentication is as defined by TS 33.102 [4] subclause 5.1.2 
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5.1 .3 User data and signalling data confidentiality 

5.1.3.1 Ciphering requirements 

Ciphering may be provided to RRC-signalling to prevent UE tracking based on cell level measurement reports, 
handover message mapping, or cell level identity chaining. RRC signalling confidentiality is an operator option. 

Synchronization of the input parameters for ciphering shall be ensured for the protocols involved in the ciphering. 

The NAS signalling may be confidentiality protected. NAS signalling confidentiality is an operator option. 

NOTE 1 : RRC and NAS signalling confidentiality protection is recommended to be used. 
User plane confidentiality protection shall be done at PDCP layer and is an operator option. 

NOTE 2: User plane confidentiality protection is recommended to be used. 

NOTE 3: Confidentiality protection for RRC and UP is applied at the PDCP layer, and no layers below PDCP are 
confidentiality protected. Confidentiality protection for NAS is provided by the NAS protocol. 

5.1 .3.2 Algorithm Identifier Values 

All algorithms specified in this subclause are algorithms with a 128-bit input key except Null ciphering algorithm. 

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list 
below. 

Each EPS Encryption Algorithm (EEA) will be assigned a 4-bit identifier. Currently, the following values have been 
defined for NAS, RRC and UP ciphering: 

"OOOO2" EEAO Null ciphering algorithm 

"OOOI2" 128-EEAl SNOW 3G based algorithm 

"OOIO2" 128-EEA2 AES based algorithm 
The remaining values have been reserved for future use. 

UEs and eNBs shall implement EEAO, 128-EEAl and 128-EEA2 for both RRC signalling ciphering and UP ciphering. 
UEs and MMEs shall implement EEAO, 128-EEAl and 128-EEA2 for NAS signalling ciphering. 
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5.1 .4 User data and signalling data integrity 

5.1 .4.1 Integrity requirements 

Synchronization of the input parameters for integrity protection shall be ensured for the protocols involved in the 
integrity protection. 

Integrity protection, and replay protection, shall be provided to NAS and RRC-signalling. 

All NAS signaling messages except those explicitly listed in TS 24.301 [9] as exceptions shall be integrity-protected. 
All RRC signaling messages except those explicitly listed in TS 36.331 [21] as exceptions shall be integrity-protected. 

User plane packets between the eNB and the UE shall not be integrity protected. 

5.1 .4.2 Algorithm Identifier Values 

All algorithms specified in this subclause are algorithms with a 128-bit input key. 

NOTE: Deviations from the above requirement have to be indicated explicitly in the algorithm identifier list 
below. 

Each EPS Integrity Algorithm (EIA) will be assigned a 4-bit identifier. Currently, the following values have been 
defined: 

"OOOI2" 128-EIAl SNOW 3G 

"OOIO2" 128-EIA2 AES 
The remaining values have been reserved for future use. 

UEs and eNBs shall implement 128-EIAl and 128-EIA2 for RRC signalling integrity protection. 
UEs and MMEs shall implement 128-EIAl and 128-EIA2 for NAS signalling integrity protection. 
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5.2 Security visibility and configurability 

Although in general the security features should be transparent to the user, for certain events and according to the user's 
concern, greater user visibility of the operation of following security feature shall be provided: 

indication of access network encryption: the property that the user is informed whether the confidentiality of user 
data is protected on the radio access link, in particular when non-ciphered calls are set-up; 

The ciphering indicator feature is specified in 3GPP TS 22.101 [23]. 

Configurability is the property that the user can configure whether the use or the provision of a service should depend 
on whether a security feature is in operation. A service can only be used if all security features, which are relevant to 
that service and which are required by the configurations of the user, are in operation. The following configurability 
features are suggested: 

enabling/disabling user-USIM authentication: the user should be able to control the operation of user-USIM 
authentication, e.g., for some events, services or use. 

5.3 Security requirements on eNodeB 

5.3.1 General 

The security requirements given in this section apply to all types of eNodeBs. More stringent requirements for specific 
types of eNodeBs may be defined in other documents. 

5.3.2 Requirements for eNB setup and configuration 

Setting up and configuring eNBs shall be authenticated and authorized so that attackers shall not be able to modify the 
eNB settings and software configurations via local or remote access. 

1. Security associations are required between the EPS core and the eNB and between adjacent eNBs, connected via 
X2. These security association establishments shall be mutually authenticated and used for communication 
between the entities. The security associations shall be realized according to clause 11 and 12 of this 
specification. 

2. Communication between the remote/local O&M systems and the eNB shall be mutually authenticated. 

3. The eNB shall be able to ensure that software/data change attempts are authorized 

4. The eNB shall use authorized data/software. 

5. Sensitive parts of the boot-up process shall be executed with the help of the secure environment. 

6. Confidentiality of software transfer towards the eNB shall be ensured. 

7. Integrity protection of software transfer towards the eNB shall be ensured. 

5.3.3 Requirements for key management inside eNB 

The EPS core network provides subscriber specific session keying material for the eNBs, which also hold long term 
keys used for authentication and security association setup purposes. Protecting all these keys is important. 

1. Keys stored inside eNBs shall never leave a secure environment within the eNB except when done in accordance 
with this or other 3GPP specifications. 
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5.3.4 Requirements for handling User plane data for the eNB 

It is eNB's task to cipher and decipher user plane packets between the Uu reference pointand the S1/X2 reference 
points. 

1 . User plane data ciphering/deciphering shall take place inside the secure environment where the related keys are 
stored. 

2. The transport of user data over Sl-U and X2-U shall be integrity, confidentially and replay-protected from 
unauthorized parties. If this is to be accomplished by cryptographic means, clause 12 shall be applied. 

NOTE: The use of cryptographic protection on Sl-U and X2-U is an operator's decision. In case the eNB has been 
placed in a physically secured environment then the 'secure environment' may include other nodes and 
links beside the eNB. 

5.3.4a Requirements for handling Control plane data for the eNB 

It is eNB's task to provide confidentiality and integrity protection for control plane packets on the S1/X2 reference 
points. 

1 . Control plane data ciphering/deciphering shall take place inside the secure environment where the related keys 
are stored. 

2. The transport of control plane data over Sl-MME and X2-C shall be applied to integrity-, confidentiality- and 
replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, clause 1 1 shall 
be applied. 

NOTE: The use of cryptographic protection on Sl-MME and X2-C is an operator's decision. In case the eNB has 
been placed in a physically secured environment then the 'secure environment' may include other nodes 
and links beside the eNB. 

5.3.5 Requirements for secure environment of the eNB 

The secure environment is logically defined within the eNB and is a composition of functions for the support of 
sensitive operations. 

1. The secure environment shall support secure storage of sensitive data, e.g. long term cryptographic secrets and 
vital configuration data. 

2. The secure environment shall support the execution of sensitive functions, e.g. en-/decryption of user data and 
the basic steps within protocols which use long term secrets (e.g. in authentication protocols). 

3. Sensitive data used within the secure environment shall not be exposed to external entities. 

4. The secure environment shall support the execution of sensitive parts of the boot process. 

5. The secure environment's integrity shall be assured. 

6. Only authorised access shall be granted to the secure environment, i.e. to data stored and used within, and to 
functions executed within. 



5.4 Void 
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6 Security Procedures between UE and EPC Network 

Elements 

6.1 Authentication and key agreement 
6.1.1 AKA procedure 

EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN. 

A Rel-99 or later USIM application on a UICC shall be sufficient for accessing E-UTRAN, provided the USIM 
application does not make use of the separation bit of the AMP in a way described in TS 33.102 [4] Annex F. Access to 
E-UTRAN with a 2G SIM or a SIM application on a UICC shall not be granted. 

An ME that has E-UTRAN radio capability shall support the USIM-ME interface as specified in TS 31.102 [13] 

EPS AKA shall produce keying material forming a basis for user plane (UP), RRC, and NAS ciphering keys as well as 
RRC and NAS integrity protection keys. 

NOTE 1 : Key derivation requirements of AS and NAS keys can be found in subclause 7.2.1 

During the authentication, the USIM shall verify the freshness of the authentication vector that is used. The MME sends 
to the USIM via ME the random challenge RAND and an authentication token AUTN for network authentication from 
the selected authentication vector. At receipt of this message, the USIM shall verify whether AUTN can be accepted 
and if so, produces a response RES. USIM shall compute CK and IK. 

An ME accessing E-UTRAN shall check during authentication that the "separation bit" in the AMF field of AUTN is 
set to 1 and reject authentication otherwise with a CAUSE value. The "separation bit" is bit of the AMF field of 
AUTN. 

UE shall compute Kasme from CK, IK, and serving network's identity (SN id) using the KDF as specified in Annex A. 
SN id binding implicitly authenticates the serving network's identity when the derived keys from Kasme are successfully 
used. 

NOTE 2: This separation bit in the AMF can not be used anymore for operator specific purposes as described by 
TS 33.102 [4], Annex F 

NOTE 3: The HSS needs to ensure that the MME requesting the authentication data is entitled to use the SN id used 
to calculate Kasme- The exact details of how to achieve this are not covered in this specification. 

NOTE 4: If the keys CK, IK resulting from an EPS AKA run were stored in the fields already available on the 
USIM for storing keys CK and IK this could lead to overwriting keys resulting from an earlier run of 
UMTS AKA. This would lead to problems when EPS security context and UMTS security context were 
held simultaneously (as is the case when security context is stored e.g. for the purposes of Idle Mode 
Signaling Reduction). Therefore, "plastic roaming" where a UICC is inserted into another ME will 
necessitate an EPS AKA authentication run if the USIM does not support EMM parameters storage. 

UE shall respond with User authentication response message including RES in case of successful AUTN verification as 
described in TS 33.102[4] and successful AMF verification as described above. Otherwise UE shall send User 
authentication reject message with a proper CAUSE value. 

Figure 6.1.1-1 describes EPS AKA procedure, which is based on UMTS AKA (see TS 33.102[4]). The following keys 
are shared between UE and HSS: 

• K is the permanent key stored on the USIM on a UICC and in the Authentication Centre AuC. 



• 



CK, IK is the pair of keys derived in the AuC and on the USIM during an AKA run. CK, IK shall be handled 
differently depending on whether they are used in an EPS security context or a legacy security context, as 
described in subclause 6.1.2. 
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As a result of the authentication and key agreement, an intermediate key K^sme shall be generated which is shared 
between UE and ASME i.e. the MME cfr Figure 6.1.1-1. How this is done is described in subclause 6.1.2. 

ME/USIM MME 

User authentication request (RAND, AUTN, KSIasme) 

User authentication response (RES) 

User authentication reject (CAUSE) 

Figure 6.1.1-1: EPS user authentication (EPS AKA) 

6.1 .2 Distribution of autinentication data from HSS to serving network 

The purpose of this procedure is to provide the MME with one or more EPS authentication vectors (RAND, AUTN, 
XRES, Kasme) from the user's HE (HSS) to perform a number of user authentications. 

NOTE 1 : It is recommended that the MME fetch only one EPS authentication vector at a time as the need to perform 
AKA runs has been reduced in EPS through the use of a more elaborate key hierarchy. In particular, 
service requests can be authenticated using a stored Kasme without the need to perform AKA. 
Furthermore, the sequence number management schemes in TS 33.102, Annex C [4], designed to avoid 
re-synchronisation problems caused by interleaving use of batches of authentication vectors, are only 
optional. Re-synchronisation problems in EPS can be avoided, independently of the sequence number 
management scheme, by immediately using an authentication vector retrieved from the HSS in an 
authentication procedure between UE and MME. 

MME HE 

Authentication data request 
IMSI, SN identity. Network Type 



Authentication data response 

EPS-Authentication Vector (s) 

A 

Figure 6.1.2-1 : Distribution of authentication data from IHE to lUIIUIE 

An EPS authentication vector is derived from the authentication vector defined in TS 33.102 [4] clause 6.3.2. To derive 
the key Kasme in the HE, the KDF as specified in Annex A is used which shall contain following mandatory input 
parameters; CK, IK and SN identity. 

If the Network Type equals E-UTRAN then the "separation bit" in the AMF field of AUTN shall be set to 1 to indicate 
to the UE that the authentication vector is only usable for AKA in an EPS context, if the "separation bit" is set to 0, the 
vector is usable in a non-EPS context only (e.g. GSM, UMTS). For authentication vectors with the "separation bit" set 
to 1, the secret keys CK and IK generated during AKA shall never leave the HSS. 

The MME invokes the procedures by requesting authentication vectors from the HE (Home environment). 

The authentication data request shall include the IMSI, the Serving Network identity i.e. MCC + MNC, and the 
Network Type (I.e. E-UTRAN) 

Upon the receipt of the authentication data request from the MME, the HE may have pre-computed the required 
number of EPS authentication vectors and retrieve them from the HSS database or may compute them on demand. 

NOTE 2: For Kasme the possibilities for pre-computation are restricted due to the PLMN-binding. 
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The HE sends an authentication response back to the MME that contains the requested information. If multiple EPS 
authentication vectors had been requested then they are ordered based on their sequence numbers. 

6.1 .3 User identification by a permanent identity 

The user identification mechanism should be invoked by the serving network whenever the user cannot be identified by 
means of a temporary identity (GUTI). In particular, it should be used when the serving network cannot retrieve the 
IMSI based on the GUTI by which the user identifies itself on the radio path. 

The mechanism described in figure 6.1.3-1 allows the identification of a user on the radio path by means of the 
permanent subscriber identity (IMSI). 



ME/USIM 



MME 



Identity Request 



Identity Response (IMSI) 



Figure 6.1 .3-1 : User identity query 

The mechanism is initiated by the MME that requests the user to send its permanent identity. The user's response 
contains the IMSI in cleartext. This represents a breach in the provision of user identity confidentiality. 

6.1 .4 Distribution of IMSI and authentication data within one serving 
network domain 

The purpose of this procedure is to provide a newly visited MME with authentication data from a previously visited 
MME within the same serving network domain. 

NOTE: The following procedure in this clause is based on TAU procedure and it can also be applied for Attach 

procedure where all the corresponding texts for 'TAU' in the following procedure should be replaced with 
'Attach'. 

The procedure is shown in Figure 6. 1.4-1 



MMEn 



MMEo 



GUTIo II Complete TAU message 



IMSI II authentication data 



Figure 6.1 .4-1 : Distribution of IIVISI and authentication data within one serving domain 

The procedure shall be invoked by the newly visited MMEn after the receipt of a Tracking Area update request from the 
user wherein the user is identified by means of a temporary user identity GUTIo and the Tracking area identity TAIo 
under the jurisdiction of a previously visited MMEo that belongs to the same serving network domain as the newly 
visited MMEn. 

The protocol steps are as follows: 
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a) The MMEn sends a message to the MMEo, this message contains GUTIo and the received TAU message. 

b) The MMEo searches the user data in the database and checks the integrity protection on the TAU message. 
If the user is found and the integrity check succeeds, the MMEo shall send a response back that: 

i) shall include the IMSI, 

ii) may include a number of unused EPS -authentication vectors ordered on a first-in / first-out basis, and 

iii) may include any EPS security contexts it holds 

The MMEo subsequently deletes the EPS -authentication vectors and any EPS security contexts which have been 
sent. 

If the user cannot be identified or the integrity check fails, then the MMEo shall send a response indicating that 
the user identity cannot be retrieved. 

c) If the MMEn receives a response with an IMSI, it creates an entry and stores any EPS-authentication vectors and 
any EPS security context that may be included. 

If the MMEn receives a response indicating that the user could not be identified, it shall initiate the user 
identification procedure described in clause 6.1.3. 

6.1 .5 Distribution of IMSI and authentication data between different 
serving network domains 

In general, the distribution of IMSI and authentication between MMEs belonging to different serving network domains 
of shall be performed as described for the distribution of IMSI and authentication data within the same service network 
domain in subclause 6. 1.4. In particular, the current EPS security context data may be transferred between MMEs 
belonging to different serving network domains. However, the following three cases are exceptions related to the 
distribution of authentication vectors between SGSNs and MME's: 

a) MMEtoMME 

Unused EPS authentication vectors shall not be distributed between MME's belonging to different serving 
domains (PLMNs) 

UMTS authentication vectors that were previously received from an SGSN shall not be forwarded between 
MMEs. 

b) SGSNtoMME 

An SGSN may forward unused UMTS authentication vectors to an MME. 

An MME shall not use unused UMTS authentication vectors forwarded from an SGSN in E-UTRAN 
procedures. 

c) MME to SGSN 

UMTS AVs which were previously stored in the MME may be forwarded back towards the same SGSN. 

UMTS AVs which were previously stored in the MME shall not be forwarded towards other SGSNs. 

EPS authentication vectors shall not be forwarded from an MME towards an SGSN. 

NOTE: This is due to the fact that in an EPS-AV the CK and IK are not available for the MME and hence also not 
for the SGSN when an EPS-AV would be forwarded. 



6.2 EPS key hierarchy 

Requirements on EPC and E-UTRAN related to keys: 
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a) The EPC and E-UTRAN shall allow for use of encryption and integrity protection algorithms for AS and NAS 
protection having keys of length 128 and for future use the network interfaces shall be prepared to support 256 
bit keys. 

b) The keys used for UP, NAS and AS protection shall be dependent on the algorithm with which they are used. 

c) As part of the initial attach request from the UE, ME shall signal the UE security capabilities to the MME. 
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Figure 6.2-1 : Key hierarchy in E-UTRAN 

The key hierarchy (see Figure 6.2-1) includes following keys: KeNB, Knasiih, KNASenc, Kupenc, KRRCi„t and KRRCenc 

• KeNB is a key derived by UE and MME from Kasme when the UE goes to ECM -CONNECTED state or by UE 
and target eNB during eNB handover. 

Keys for NAS traffic: 

• KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm 
This key is derived by UE and MME from Kasme, as well as an identifier for the integrity algorithm using the 
KDF as specified in Annex A. 

• KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption 
algorithm. This key is derived by UE and MME from Kasme, as well as an identifier for the encryption 
algorithm using the KDF as specified in Annex A. 

Keys for UP traffic: 

• Kupenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. 
This key is derived by UE and eNB from KeNB, as well as an identifier for the encryption algorithm using the 
KDF as specified in Annex A. 

Keys for RRC traffic: 

• KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity 

algorithm. Krrcim is derived by UE and eNB from KeNB, as well as an identifier for the integrity algorithm 
using the KDF as specified in Annex A. 
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KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption 
algorithm. K^RCenc is derived by UE and eNB from KeNB as well as an identifier for the encryption algorithm 
using the KDF as specified in Annex A. 



Intermediate keys: 

NH is a key derived by UE and MME to provide forward security as described in clause 7.2.8. The NH is sent 
by the MME to the eNB using SlsignalHng. 

KeNB* is a key derived by UE and eNB when performing an horizontal or vertical key derivation as specified in 
clause 7.2.8 using a KDF as specified in Annex A. 

Figure 6.2-2 shows the dependencies between the different keys, and how they are derived from the network nodes 
point of view. Figure 6.2-3 shows the corresponding relations and derivations as performed in the ME. 
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Figure 6.2-2: Key distribution and l<ey derivation schieme for EPS (in particular E-UTRAN) for network 

nodes. The basic derivations are covered in the figure, but derivations performed at, 

e.g. inter-RAT mobility is not shown. Two dashed input to a KDF means one of the input is taken 

depending on condition met. 
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Figure 6.2-3: Key derivation scheme for EPS (in particular E-UTRAN) for the ME. 

The basic derivations are covered in the figure, but derivations performed at, 

e.g. inter-RAT mobility is not shown. Two dashed input to a KDF means one of the input is taken 

depending on condition met. 

As the figures 6.2-2 and 6.2-3 show, the length of Kasme and K^nb is 256 bits, the length of NH is 256bits, and 256-bit 
NAS, UP and RRC keys are always derived from Kasme and K^nb respectively. In case the encryption or integrity 
algorithm used to protect NAS, UP or RRC requires a 128-bit key as input, the key is truncated and the 128 least 
significant bits are used. 

NOTE: Figures 6.2-2 and 6.2-3 do not include the key handling branches for forward security. This is described in 
clause 7.2.8 and Figure 7.2.8.1-1. 

The function Trunc takes as input a 256-bit string, and returns a truncated output as defined in Annex A.7. 



6.3 EPS key identification 



The key Kasme shall be identified by the key set identifier eKSI. eKSI may be either of type KSIasme or of type 
KSIsGSN- An eKSI shall be stored in the UE and the MME together with Kasme and the temporary identifier GUTl, if 
available. 

NOTE 1: the GUTI points to the MME where the Kasme is stored. 

The key set identifier KSIasme is a parameter which is associated with the Kasme derived during EPS AKA 
authentication. The key set identifier KSIasme is allocated by the MME and sent with the authentication request 
message to the mobile station where it is stored together with the Kasme- 
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The key set identifier KSIsgsn is a parameter which is associated with the mapped Kasme derived fi-om UMTS keys 
during inter-RAT mobihty, cf. clauses 9 and 10 of the present specification. The key set identifier KSIsgsn is generated 
in both the UE and the MME respectively when deriving the mapped Kasme during idle procedures in E-UTRAN and 
during handover from GERANAJTRAN to E-UTRAN. The KSIsgsn is stored together with the mapped Kasme- 

The purpose of the KSIasme is to make it possible for the UE and the MME to identify a native Kasme without invoking 
the authentication procedure. This is used to allow re-use of the Kasme during subsequent connection set-ups. 

The purpose of the KSIsgsn is to make it possible for the UE and the MME to indicate the use of the mapped Kasme in 
inter-RAT mobility procedures. For details cf clauses 9 and 10. 

KSIasme and KSIsgsn have the same format. The format of eKSI shall allow a recipient of such a parameter to 
distinguish whether the parameter is of type 'KSIasme' or of type 'KSIsgsn '• The format shall further contain a value 
field. The value fields of KSIasme nd KSIsgsn are three bits each. Seven values are used to identify the key set. A value 
of '111' is used by the mobile station to indicate that a valid Kasme is not available for use. Format of eKSI is described 
in [9]. 

At deletion of the Kasme^ the KSIasme is set to '111'. The value '1 11' in the other direction from network to mobile 
station is reserved. 

NOTE 2: In addition to EPS security contexts, the UE may also cache UMTS security contexts. These UMTS 
security contexts are identified by the KSI, as defined in TS 33.102 [4]. 

6.4 Handling of EPS security contexts 

Any EPS security context shall be deleted from the ME if: 

a) the UICC is removed from the ME when the ME is in power on state; 

b) the ME is powered up and the ME discovers that a UICC different from the one which was used to create the EPS 

security context has been inserted to the ME; 

c) the ME is powered up and the ME discovers that no UICC has been inserted to the ME. 

Kasme shall never be transferred from the EPC to an entity outside the EPC. 

Both the UE and MME shall be capable of storing one non-current EPS security context and one current EPS security 
context in volatile memory. In addition, while connected to E-UTRAN the UE and MME shall be capable of storing in 
volatile memory the NCC, NH and the related Kasme used to compute keying material for the current EPS AS security 
context. 

Any successful run of an EPS AKA creates, by the definition in clause 3, a partial native EPS security context. This 
context shall overwrite any existing non-current EPS security context. 

After a successful run of a NAS SMC relating to the eKSI associated with an EPS security context, this context 
becomes the current EPS security context and shall overwrite any existing current EPS security context. 

The rules for handling security contexts at transition to EMM-DEREGISTRED are given in clause 7.2.5.1. The rules for 
handling security contexts after a handover to E-UTRAN are given in clause 9.2.2.1. 

Storage of the EPS NAS security context, excluding the keys KNASim and KNASenc, in the UE during power-off: 

a) If the ME does not have a full native EPS NAS security context in volatile memory, any existing native EPS 
NAS security context stored on the UICC or in non-volatile memory of the ME shall be marked as invalid. 

b) If the USIM supports EMM parameters storage, then the ME shall store the full native EPS NAS security 
context parameters on the USIM, mark the native EPS NAS security context on the USIM as valid, and not 
keep any native EPS NAS security context in non-volatible ME memory. 

c) If the USIM does not support EMM parameters storage, then the ME shall store the full native EPS NAS 
security context in a non-volatible part of its memory, and mark the native EPS NAS security context in its non- 
volatile memory as valid. 

After power-on of the ME, the ME shall retrieve native EPS NAS security context stored on the USIM if the USIM 
supports EMM parameters storage and if the stored native EPS NAS security context on the USIM is marked as valid. If 



£75/ 



3GPP TS 33.401 version 8.4.0 Release 8 27 ETSI TS 133 401 V8.4.0 (2009-07) 

the USIM does not support EMM parameters storage the ME shall retrieve the stored native EPS NAS security context 
from its non-volatile memory if the native EPS NAS security context is marked as valid. The ME shall derive the 
KNASint and Knaschc after retrieving the stored EPS NAS security context; see Annex A on NAS key derivation. If the 
ME cannot retrieve native EPS NAS security context from any of these two places, the ME shall signal "no key 
available" in the Attach Request. The retrieved native security context shall be the current EPS security context. 

NOTE: Only native EPS NAS security context is stored in the EMM parameters file on the USIM or in non-volatile 
ME memory. A mapped EPS NAS security context is never stored in these two places. 
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7 Security Procedures between UE and EPC Access 

Network Elements 

7.1 Mechanism for user identity confidentiality 

The MME shall allocate a GUTI to a UE in order to support the subscriber identity confidentiality. The GUTI is defined 
in TS 23.003 [3]. 

S-TMSI, the shortened form of the GUTI, is used to support the subscriber identity confidentiality with more efficient 
radio signalling procedures (e.g. paging and Service Request). A new GUTI shall be sent to the UE only after a 
successful activation of NAS security. 

7.2 Handling of user-related keys in E-UTRAN 

7.2.1 E-UTRAN key setting during AKA 

Authentication and key setting are triggered by the authentication procedure. Authentication and key setting may be 
initiated by the network as often as the network operator wishes. Key setting can occur as soon as the identity of the 
mobile subscriber (i.e. GUTI or IMSI) is known by the MME. Key Kasme is stored in the MME and key Ke^B is derived 
using the KDF as specified in Annex A from the key Kasme and transferred to the UE's serving eNB when needed. 
Kasme is stored in the UE and MME and updated with the next authentication procedure. 

The RRC and UP keys are derived from the KeNB using the KDF as specified in Annex A when needed. 

If an authentication procedure is performed while the UE is in ECM -CONNECTED state, the new NAS keys shall be 
taken in use in the MME and the UE by means of the NAS security mode set-up procedure (see subclause 7.2.4). The 
AS keys shall be taken into use with the next AS security mode set-up procedure (see subclause 7.2.4) or with the key 
change on the fly procedure (see subclause 7.2.9). 

7.2.2 E-UTRAN key identification 

Clause 6.3 of this specification states how the key Kasme is identified, namely by the key set identifier eKSI. Keys 
Knasciic and KNAsint in the E-UTRAN key hierarchy specified in clause 6.2, which are derived from Kasme, can be 
uniquely identified by eKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier}, 
which are used to derive these keys from Kasme according to Annex A. 

The intermediate key NH as defined in clause 7 can be uniquely determined by the key set identifier, eKSI, together 
with the initial KeNB derived from the current NAS security context for use during the ongoing CONNECTED state and 
a counter counting how many NH-derivations have already been performed from this initial KeNB-according to Annex 
A.4. The next hop chaining count, NCC, represents the 3 least significant bits of this counter.. 

Intermediate key KeNB*, defined in clause 7, as well as keys KgNB, KRRCim, K^RCenc, and Kypenc in the E-UTRAN key 
hierarchy specified in clause 6.2, which are derived from Kasme, can be uniquely identified by eKSI together with those 
parameters from the set { uplink NAS COUNT, algorithm distinguisher, algorithm identifier, NCC, and sequence of 
PCIs and EARFCN-DLs used in horizontal key derivations with this NCC}, which are used to derive these keys from 
Kasme according to clause 7 and Annex A. 

It is specified in the remainder of clause 7, as well as in clause 9 and 10, which of the above parameters need to be 
included in a security-relevant message to allow the entity receiving the message to uniquely identify a certain key. 

7.2.3 E-UTRAN key lifetimes 

All E-UTRAN keys are derived based on a Kasme- The key hierarchy which is described in clause 6.2 does not allow 
direct update to RRC and UP keys, but fresh RRC and UP keys are derived based on a fresh KeNB, which is bound to 
certain dynamic parameters (like PCI) and fresh key derivation parameter(s) in state transitions (like NAS uplink 
COUNT). This results as fresh RRC and UP keys in the eNB between inter-eNB handovers and state transitions (see 
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subclauses 7.2.6 to 7.2.8).. The handling (creation, modification and update) of the E-UTRAN keys in the various state 
transitions is described in clauses 7.2.5, 7.2.6, 7.2.7 and 7.2.8. 

Kasme shall be created only by running a succesful AKA or by the inter-RAT procedures towards E-UTRAN (cfr 
clauses 9 and 10). In case Kasme is invalidated by the UE, a KSIasme with value "111" shall be sent by the UE to the 
network, which can initiate (re-)authentication procedure to get a new Kasme based on a successful AKA authentication. 

7.2.4 Security mode command procedure and algorithm negotiation 

7.2.4.1 Requirements for algorithm selection 

a) An active UE and a serving network shall agree upon algorithms for 

RRC ciphering and RRC integrity protection (to be used between UE and eNB) 

UP ciphering (to be used between UE and eNB) 

NAS ciphering and NAS integrity protection (to be used between UE and MME) 

b) The serving network shall select the algorithms to use dependent on 

the UE security capabilities of the UE, 

the configured allowed list of security capabilities of the currently serving network entity 

c) The same set of ciphering and integrity algorithms shall be supported by the UE both for AS and NAS level. 

d) Each selected algorithm shall be acknowledged to the UE in an integrity protected way such that the UE is 
ensured that the algorithm selection was not manipulated, i.e. that the UE security capabilities were not bidden 
down. 

e) The UE security capabilities the ME sent to the network shall be repeated in an integrity protected NAS level 
message to the ME such that "bidding down attacks" against the UE's security capabilities can be detected by 
the ME. The UE security capabilities apply to both AS and NAS level security. 

f) Separate AS and NAS level security mode command procedures are required. AS level security mode 
command procedure configures AS security (RRC and UP) and NAS level security mode command procedure 
configures NAS security. 

a. Both integrity protection and ciphering for RRC are activated within the same AS SMC procedure, 
but not necessarily within the same message. 

b. User plane ciphering is activated at the same time as RRC ciphering. 

g) It shall be possible that the selected AS and NAS algorithms are different at a given point of time. 

7.2.4.2 Procedures for AS algorithm selection 

7.2.4.2.1 Initial AS security context establishment 

Each eNB shall be configured via network management with lists of algorithms which are allowed for usage. There 
shall be one list for integrity algorithms, and one for ciphering algorithms. These lists shall be ordered according to a 
priority decided by the operator. When AS security context is established in the eNB, the MME shall send the UE EPS 
security capabilities to the eNB. The eNB shall choose the ciphering algorithm which has the highest priority from its 
configured list and is also present in the UE EPS security capabilities. The eNB shall choose the integrity algorithm 
which has the highest priority from its configured list and is also present in the UE EPS security capabilities. The 
chosen algorithms shall be indicated to the UE in the AS SMC. The ciphering algorithm is used for ciphering of the user 
plane and RRC traffic. The integrity algorihtm is used for integrity protection of the RRC traffic. 

7.2.4.2.2 X2-handover 

At handover from a source eNB over X2 to a target eNB, the source eNB shall include the UE EPS security capabilities 
in the handover request message. The target eNB shall select the algorithm with highest priority from the UE EPS 
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security capabilities according to the prioritized locally configured list of algorithms (this applies for both integrity and 
ciphering algorithms). The chosen algorithms shall be indicated to the UE in the handover command. In the path-switch 
message, the target eNB shall send the UE EPS security capabilities received from the source eNB to the MME. The 
MME shall verify that the UE EPS security capabilities received from the eNB are the same as the UE EPS security 
capabilities that the MME has stored. If there is a mismatch, the MME may log the event and may take additional 
measures, such as raising an alarm. 

7.2.4.2.3 S1 -handover 

At handover from a source eNB to a target eNB over S 1 (possibly including an MME change and hence a transfer of the 
UE security capabilities from source MME to target MME), the target MME shall send the UE EPS security capabilities 
to the target eNB in the SI AP HANDOVER REQUEST message. The target eNB shall select the algorithm with 
highest priority from the UE EPS security capabilities according to the prioritized locally configured list of algorithms 
(this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the 
handover command. 

7.2.4.2.4 Intra-eNB handover 

It is not required to change the AS security algorithm during intra-eNB handover. 

7.2.4.3 Procedures for NAS algorithm selection 

7.2.4.3.1 Initial NAS security context establishment 

Each MME shall be configured via network management with lists of algorithms which are allowed for usage. There 
shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered 
according to a priority decided by the operator. 

When the NAS security context is established, e.g., by a TAU Accept, Attach Accept or by NAS SMC message, the 
MME shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm, and indicate them in the 
corresponding integrity protected message to UE and shall also include the UE security capabilities into that message. 
The UE shall verify that the message from the MME contains the correct UE security capabilities. If so, the UE shall 
reply with an integrity protected SMC Complete message, protected by the integrity algorithm selected by the MME. 
This enables detection of attacks where an attacker has modified the UE security capabilities in the initial NAS 
message. The MME shall select the NAS algorithms which have the highest priority according to the ordered lists. 

7.2.4.3.2 MME change 

In case there is change of MMEs and algorithms to be used for NAS, the target MME shall send an integrity protected 
Security Mode Command message which includes integrity and ciphering algorithms selected for NAS protection and 
UE EPS security capabilities. The UE verifies that the message from the MME contains the correct UE security 
capabilities. If so, the UE shall reply with an integrity protected SMC Complete message. The MME shall select the 
NAS algorithms which have the highest priority according to the ordered lists (see 7.2.4.3.1). 

NOTE: After an SI -handover with MME change a TAU procedure is executed. The same is true for an inter-RAT 
handover to E-UTRAN and for both inter- and intra-RAT idle mode mobility resulting in a change of 
MMEs. 

7.2.4.4 NAS security mode command procedure 

The NAS SMC procedure consists of a roundtrip of messages between MME and UE. The MME sends the NAS 
security mode command to the UE and the UE replies with the NAS security mode complete message. 

The NAS security mode command message from MME to UE shall contain the replayed UE security capabilities, the 
selected NAS algorithms, the eKSI for identifying Kasme^ and both NONCEue and NONCEmme in case as specified in 
section 9.1.2. This message shall be integrity protected with NAS integrity key based on Kasme indicated by the eKSI in 
the message. See figure 7.2.4.4-1. 

UE shall verify the integrity of the NAS security mode command message. If successfully verified, UE shall start NAS 
integrity protection and ciphering/deciphering and sends the NAS security mode complete message to MME ciphered 
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and integrity protected with the selected NAS algorithm indicated in the NAS security mode command message and 
NAS keys based on Kasme indicated by the eKSI in the NAS security mode command message. 

NAS downlink ciphering at the MME shall start after receiving the NAS security mode complete message. NAS uplink 
deciphering at the MME starts after sending the NAS security mode command message. NAS uplink ciphering and 
downlink deciphering at the UE shall start after receiving and successfully verifying the NAS security mode command 
message. The NAS security mode complete message shall include IMEI in case MME requested it in the NAS SMC 
Command message. 

If any verification of the NAS security mode command is not successful in the ME, the ME shall reply with an 
unprotected NAS security mode reject message (see TS 24.301 [9]). 

Only after EPS AKA the NAS security mode command message shall reset NAS uplink and downlink COUNT values. 
Both the NAS security mode command and NAS security mode complete messages are protected based on reset 
COUNT values (zero). NAS SMC always changes the NAS keys (i.e. due to EPS AKA with new Kasme and eKSI or 
due to the algorithms change). 

ME MME 

Start integrity 
protection 

NAS Security Mode Command (eKSI, UE sec capabilities. 

Ciphering algorithm. Integrity algorithm, 

[IMEI request,] [NONCEue, NONCEmme.] NAS-MAC) 



Verify NAS SMC integrity. If Start uplink 

succesful, start ciphering/ deciphering 

deciphering and integrity 
protection and send NAS 
Security Mode Complete. 

NAS Security Mode Complete ([IMH,] NAS-MAC) 

► 

Start downlink ciphering 

Figure 7.2.4.4-1 : NAS security mode command procedure 

7.2.4.5 AS security mode command procedure 

The AS SMC procedure consists of a roundtrip of messages between eNB and UE. The eNB sends the AS security 
mode command to the UE and the UE replies with the AS security mode complete message. See figure 7.2.4.5-1. 

The AS security mode command message from eNB to UE shall contain the selected AS algorithms. This message shall 
be integrity protected with RRC integrity key based on the current Kasme- 

The AS security mode complete message from UE to eNB shall be integrity protected with the selected RRC algorithm 
indicated in the AS security mode command message and RRC integrity key based on the current Kasme- 

RRC and UP downlink ciphering (encryption) at the eNB shall start after sending the AS security mode command 
message. RRC and UP uplink deciphering (decryption) at the eNB shall start after receiving and successful verification 
of the AS security mode complete message. 

RRC and UP uplink ciphering (encryption) at the UE shall start after sending the AS security mode complete message. 
RRC and UP downlink deciphering (decryption) at the UE shall start after receiving and successful verification of the 
AS security mode command message 

If any control of the AS security mode command is not successful in the ME, the ME shall reply with an unprotected 
security mode failure message (see TS 36.331[21]). 

AS security mode command always changes the AS keys. 
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ME eNB 

Start RRC 
integrity protection 

AS Security Mode Command (Integrity algorithm, Ciphering algorithm, 

MAC -I) 

< 

Verify AS SM C integri ty. S tart RRC/UP 

If succesful, start RRC integrity downlink ciphering 

protection, RRCAJP downlink 
deciphering, and send AS Security 
Mode Complete. 

AS Security Mode Complete (MAC-f) 



S tart RRC/UP S tart RRC/UP 

uplink ciphering uplink deciphering 

Figure 7.2.4.5-1 : AS security setup 

7.2.5 Key handling at state transitions to and away from EMM- 
DEREGISTERED 

7.2.5.1 Transition to EMM-DEREGISTERED 

There are different reasons for transition to the EMM-DEREGISTERED state. In all cases the UE and MME shall do 
the following 

1 . If they have a full non-current native security context and a current mapped security context, then they shall 

make the non-current native security context the current one. 

2. They shall delete any mapped or partial security contexts they hold. 

Handling of the remaining authentication data for each of these cases are given below. As these are NAS messages, they 
will be integrity protected when a security context exists in the UE and MME. 

1. Attach reject: All authentication data shall be removed from the UE and MME 

2. Detach: 

a. UE-initiated 

i. If the reason is switch off then all the remaining authentication data shall be removed from the UE and 
MME with the exception of: 

the current native EPS NAS security context (as in clause 6.1.1), which should remain stored in the 
MME and UE, and 

any unused authentication vectors, which may remain stored in the MME. 

ii. If the reason is not switch off then MME and UE shall keep all the remaining authentication data. 

b. MME-initiated 

i. Explicit: all the remaining authentication data shall be kept in the UE and MME if the detach type is re- 
attach. 

ii. Implicit: all the remaining authentication data shall be kept in the UE and MME. 

c. HSS-initiated: If the message is "subscription withdrawn" then all the remaining authentication data shall be 
removed from the UE and MME. 
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If the USIM supports EMM parameters storage then the ME shall update the EPS NAS security context 
parameters on the USIM, excluding the keys KtMASim and KtMASenc, with the values of the full native EPS security 
context if it has one and if so mark the EPS NAS security context on the USIM as valid. Otherwise, the ME shall 
update the EPS NAS security context, excluding the keys KNASim and Knascmc^ in its non-volatile memory with its 
values of the full native EPS security context if it has one and if so mark the EPS NAS security context in its 
non-volatile memory as valid. 

3. TAU reject: There are various reasons for TAU reject. The action to be taken shall be as given in TS 24.301. 

For the case that the MME or the UE enter EMM-DEREGISTERED state without using any of the above procedures, 
the handling of the remaining authentication data shall be as specified in TS 24.301 [9]. 

7.2.5.2 Transition away from EMM-DEREGISTERED 

7.2.5.2.1 General 

When the UE transits from EMM-DEREGISTERED to EMM-REGISTERED/ECM-CONNECTED, there are two 
cases to consider, either a complete native EPS NAS security context exists, or it does not. 

7.2.5.2.2 With existing native EPS NAS security context 

If there is native EPS NAS security context the ME first derives the keys KNASint and Knaschc, then the UE shall transmit 
a NAS Attach Request message. This message is integrity protected, and provided there is no NAS SMC procedure 
before the AS SMC the NAS COUNT of the Attach Request message shall be used to derive the KeNB with the KDF as 
specified in Annex A. As a result of the NAS Attach Request, the eNB shall send an AS SMC to the UE to activate AS 
security. The KeNB used, is derived in the current EPS NAS security context. 

When the UE receives the AS SMC without having received a NAS Security Mode Command after the Attach/Service 
Request, it shall use the NAS COUNTof the Attach/Service Request message (i.e. the uplink NAS COUNT) that 
triggered the AS SMC to be sent as freshness parameter in the derivation of the KeNB- From this K^-nb the RRC 
protection keys and the UP protection keys shall be derived as described in subclause 7.2.1. 

The same procedure for refreshing KeNB can be used regardless of the fact if the UE is connecting to the same MME to 
which it was connected previously or to a different MME. In case UE connects to a different MME and this MME 
supports different NAS algorithms, the NAS keys have to be re-derived in the MME with the new algorithm IDs as 
input using the KDF as specified in Annex A. 

In addition, there is a need for the MME to send a NAS SMC to the UE to indicate the change of NAS algorithms and 
to take the re-derived NAS keys into use. The UE shall assure that the NAS keys used to verify the integrity of the NAS 
SMC are derived using the algorithm ID specified in the NAS SMC. The NAS SMC Command and NAS SMC 
Complete messages are protected with the new keys. 

If there is a NAS Security Mode Command after the Attach/Service Request but before the AS SMC, the UE and MME 
use the NAS COUNT of the NAS Security Mode Complete (i.e. the uplink NAS COUNT) and the related Kasme as the 
parameter in the derivation of the KeNB- From this KeNB the RRC protection keys and the UP protection keys are 
derived as described in subclause 7.2.1. 

If the USIM supports EMM parameters storage, the ME shall mark the stored EPS NAS security context on the USIM 
as invalid at the end of the transition away from EMM-DEREGISTRED. Otherwise, the ME shall mark the stored EPS 
NAS security context on its non- volatile memory as invalid at the end of the transition. 

7.2.5.2.3 With run of EPS AKA 

If there is no native EPS NAS security context available an EPS AKA run is required. If there is native EPS NAS 
security context available the MME may decide to run an EPS AKA and a NAS SMC procedure (which activates the 
EPS NAS security context based on the Kasme derived during the EPS AKA run) after the Attach Request but before 
the corresponding AS SMC), the NAS (uplink and downlink) COUNTs are reset to start values, and the start value of 
the uplink NAS COUNTshall be used as freshness parameter in the KeNB derivation from the fresh Kasme (after AKA) 
when UE receives AS SMC the K^-nb is derived from the current EPS NAS security context, i.e., the fresh Kasme is used 
to derive the KeNB The KDF as specified in Annex A shall be used to derive the KeNB- 
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NOTE: Using the start value for the uplink NAS COUNTin this case cannot lead to the same combination of 

Kasme and NAS COUNTbeing used twice. This is guaranteed by the fact that the first integrity protected 
NAS message the UE sends to the MME after AKA is the NAS SMC complete message. 

The NAS SMC complete message shall include the start value of the NAS COUNTthat is used as freshness parameter 
in the KeNB derivation and the Kasme is fresh. After an AKA, a NAS SMC needs to be sent from the MME to the UE in 
order to take the new NAS keys into use. Both NAS SMC and NAS SMC Complete messages are protected with the 
new NAS keys. 

If the USIM supports EMM parameters storage, the ME shall mark the stored EPS NAS security context on the USIM 
as invalid. Otherwise, the ME shall mark the storedEPS NAS security context on its non-volatile memory as invalid. 

7.2.6 Key handling in ECM-IDLE to ECM-CONNECTED and 
ECM-CONNECTED to ECM-IDLE transitions when in 
EMM-REGISTERED state 

7.2.6.1 General 

As a general principle, on ECM-IDLE to ECM-CONNECTED transitions when in EMM-REGISTERED state, RRC 
protection keys and UP protection keys shall be generated as described in subclause 7.2.1 while Kasme is assumed to be 
already available in the MME. 

Kasme may have been established in the MME as a result of an AKA run, or as a result of a security context transfer 
from another MME during handover or idle mode mobility. On ECM-CONNECTED to ECM-IDLE transitions, eNBs 
shall delete the keys they store such that state in the network for ECM-IDLE state UEs will only be maintained in the 
MME. 

7.2.6.2 ECM-IDLE to ECM-CONNECTED transition 

The procedure the UE uses to transit from ECM-IDLE to ECM-CONNECTED when in EMM-REGISTERED state is 
initiated by a NAS Service Request message from the UE to the MME. As the UE is in EMM-REGISTERED state, an 
EPS security context exists in the UE and the MME, and this EPS security context further contains uplink and downlink 
NAS COUNTS. The NAS Service Request message sent in EMM-REGISTERED shall be integrity protected and 
contain the next-in-sequence uplink NAS sequence number. 

Upon receipt of the NAS Service Request message, if the MME does not requires a NAS SMC procedure before 
initiating the Sl-AP procedure INITIAL CONTEXT SETUP, the MME shall derive key K^nb as specified in subclause 
A.3 using the NAS COUNT [9] corresponding to the NAS Service Request and the Kasme of the current EPS NAS 
security context. The MME shall further initialize the value of the Next hop Chaining Counter (NCC) to zero. The 
MME shall further derive a next hop parameter NH as specified in subclause A.4 using the newly derived KeNB and the 
Kasme as basis for the derivation. The MME shall further set the the value of the Next hop Chaining Counter (NCC) to 
one. This fresh {NH, NCC=1 } pair shall be stored in the MME and shall be used for the next forward security key 
derivation. The MME shall communicate the K^-nb pair to the serving eNB in the S 1 -AP procedure INITIAL 
CONTEXT SETUP. The UE shall derive the KeNB from the Kasme of the current EPS NAS security context. 

As a result of the NAS Service Request, radio bearers are established, and the eNB sends an AS SMC to the UE. When 
the UE receives the AS SMC without having received a NAS Security Mode Command, it shall use the NAS uplink 
COUNT of the NAS Service Request message that triggered the AS SMC as freshness parameter in the derivation of 
the KeNB- The KDF as specified in Annex A shall be used for the KeNB derivation using the Kasme of the current EPS 
NAS security context. The UE shall further derive the NH parameter from the newly derived Kcnb and the Kasme in the 
same way as the MME. From the KeNB the RRC protection keys and the UP protection keys are derived by the UE and 
the eNB as described in subclause 6.2. 

If the ECM-IDLE to ECM-CONNECTED procedure contains an EPS AKA run and a NAS SMC procedure (which are 
optional), the NAS uplink and downlink COUNT for the new Kasme shall be set to the start values (i.e. zero). If the 
ECM-IDLE to ECM-CONNECTED procedure contains an NAS SMC (which is optional), the value of the uplink NAS 
COUNT from the NAS Security Mode Complete shall be used as freshness parameter in the K^-nb derivation from fresh 
Kasme of the current EPS NAS security context when executing an AS SMC. The KDF as specified in Annex A shall be 
used for the KeNB derivation also in this case. 
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On transitions to ECM-CONNECTED, the MME should be able to check whether a new authentication is required, e.g. 
because of prior inter-provider handover. 

If the USIM supports EMM parameters storage, the ME shall mark the stored EPS NAS security context on the USIM 
as invalid. Otherwise, the ME shall mark the stored EPS NAS security context in its non-volatile memory as invalid. 

7.2.6.3 ECM-CONNECTED to ECM-IDLE transition 

On ECM-CONNECTED to ECM-IDLE transitions the eNB does no longer need to store state information about the 
corresponding UE. 

In particular, on ECM-CONNECTED to ECM-IDLE transitions: 

• The eNB and the UE shall delete the AS security context. 

• MME and the UE shall keep the EPS NAS security context stored. MME shall delete NH and NCC. 

If the USIM supports EMM parameters storage, then the ME shall update the EPS NAS security context 
parameters on the USIM, excluding the keys KNASim and Knasbiic, with its values of the full native EPS NAS 
security context if it has one and if so mark the EPS NAS security context on the USIM as valid. Otherwise, the 
ME shall update the EPS NAS security context, excluding the keys Knasjiii and Knaschc^ in its non-volatile 
memory with the values of the full native EPS NAS security context if it has one and if so mark the EPS NAS 
security context in its non-volatile memory as valid. 

7.2.7 Key handling in ECM-IDLE mode mobility 

If the "active flag" is not set in the TAU request, the TAU procedure does not establish any RRC or UP level security. 
Because of this, there is no need to derive any KeNB in this case. If the "active flag" is set in the TAU request message, 
radio bearers will be established as part of the TAU procedure. In this case a KeNB derivation is necessary, and if there 
was no subsequnet NAS SMC, the uplink NAS COUNTof the TAU request message sent from the UE to the MME is 
used as freshness parameter in the Ksnb derivation using the KDF as specified in Annex A. The TAU request shall be 
integrity protected.. 

In the case an AKA is run successfully followed by a NAS SMC from the MME as part of the TAU procedure, the 
uplink and downlink NAS COUNTshall be set to the start values (i.e. zero). 

In the case source and target MME use different NAS algorithms, the target MME re-derives the NAS keys from Kasme 
with the new algorithm identities as input and provides the new algorithm identifiers within a NAS SMC. The UE shall 
assure that the NAS keys used to verify the integrity of the NAS SMC are derived using the algorithm identity specified 
in the NAS SMC. 

If there is a NAS Security Mode Command after the TAU Request but before the AS SMC, the UE and MME use the 
NAS COUNT of the NAS Security Mode Complete (i.e. the uplink NAS COUNT) and the related Kasme as the 
parameter in the derivation of the K^nb- From this KeNB the RRC protection keys and the UP protection keys are 
derived as described in subclause 7.2.1. 

7.2.8 Key handling in handover 
7.2.8.1 General 

7.2.8.1.1 Access stratum 

The general principle of key handling at handovers is depicted in Figure 7.2.8.1-L 
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Figure 7.2.8.1-1 Model for the handover key chaining 

The following is an outline of the key handling model to clarify the intended structure of the key derivations. The 
detailed specification is provided in subclauses 7.2.8.3 and 7.2.8.4. 

Whenever an initial AS security context needs to be established between UE and eNB, MME and the UE shall derive a 
KeNB and a Next Hop parameter (NH). The K^nb and the NH are derived from the Kasme- A NH Chaining Counter 
(NCC) is associated with each Kenb and NH parameter. Every KeNB is associated with the NCC corresponding to the 
NH value from which it was derived. At initial setup, the K^-nb is derived directly from Kasme, and is then considered to 
be associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value is 
associated with the NCC value one. 

Whether the MME sends the KeNB key or the {NH, NCC} pair to the serving eNB is described in detail in subclauses 
7.2.8.3 and 7.2.8.4. The MME shall not send the NH value to eNB at the initial connection setup. 

NOTE 1 : Since the MME does not send the NH value to eNB at the initial connection setup, the NH value 
associated with the NCC value one can not be used in the next X2 handover or the next intra-eNB handover, for 
the next X2 handover or the next intra-eNB handover the horizontal key derivation (see Figure 7.2.8.1-1) will 
apply. 

The UE and the eNB use the KeNB to secure the communication between each other. On handovers, the basis for the 
KeNB that will be used between the UE and the target eNB, called KeNB*, is derived from either the currently active KeNB 
or from the NH parameter. If KeNB* is derived from the currently active KeNB this is referred to as a horizontal key 
derivation (see Figure 7.2.8.1-1) and if the KeNB* is derived from the NH parameter the derivation is referred to as a 
vertical key derivation (see Figure 7.2.8.1-1). On handovers with vertical key derivation the NH is further bound to the 
target PCI and its frequency EARFCN-DL before it is taken into use as the K^-nb in the target eNB. On handovers with 
horizontal key derivation the currently active KeNB is further bound to the target PCI and its frequency EARFCN-DL 
before it is taken into use as the K^-nb in the target eNB. 

As NH parameters are only computable by the UE and the MME, it is arranged so that NH parameters are provided to 
eNBs from the MME in such a way that forward security can be achieved. 



7.2.8.1.2 



Non access stratum 



A NAS aspect that needs to be considered is possible NAS algorithm change at MME change that could occur at a 
handover. At an eNB handover with MME relocation, there is the possibility that the source MME and the target MME 
do not support the same set of NAS algorithms or have different priorities regarding the use of NAS algorithms. In this 
case, the target MME re-derives the NAS keys from Kasme using the NAS algorithm identities as input to the NAS key 
derivation functions (see Annex A) and sends NAS SMC. All inputs, in particular the Kasme, will be the same in the re- 
derivation except for the NAS algorithm identity. 

It is essential that the NAS COUNTs are not reset to the start values unless a new Kasme is taken into use. This prevents 
that, in the case a UE moves back and forth between two MMEs the same NAS keys will be re-derived time and time 
again resulting in key stream re-use 

The NAS COUNTs shall only be reset to the start value in the following cases: 

for an EPS NAS security context created by an AKA run successfully followed by a NAS SMC, 
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or for an EPS NAS security context created through a context mapping during a handover from 
UTRAN/GERAN to E-UTRAN, 

or for an EPS NAS security context created through a context mapping during idle mode mobihty from 
UTRAN/GERAN to E-UTRAN. 

The NAS COUNT shall not be reset during idle mode mobility or handover for an already existing native EPS NAS 
security context. 

In case the target MME decides to use NAS algorithms different from the ones used by the source MME, a NAS SMC 
including eKSI (new or current value depending on whether AKA was run or not) shall be sent from the MME to the 
UE. 

The start value of NAS COUNT shall be zero (0). 

This NAS Key and algorithm handling also applies to other MME changes e.g. TAU with MME changes. 

NOTE: It is per operator's policy how to configure selection of handover types. Depending on an operator's 

security requirements, the operator can decide whether to have X2 or S 1 handovers for a particular eNB 
according to the security characteristics of a particular eNB. 

7.2.8.2 Void 

7.2.8.3 Key derivations for context modification procedure 

As outlined in subclause 7.2.8.1, whenever a fresh KeNB is calculated from the KASME(as described in Annex A.3), the 
MME shall transfer the KeNB to the serving eNB in a message modifying the security context in the eNB. The MME and 
the UE shall also compute the NH parameter from the Kasme and the fresh KeNB as described in Annex A.4 according to 
the rules in clause 7.2.9.2. An NCC value 1 is associated with the NH parameter derived from the fresh KeNB and NCC 
value with the KeNB- The UE shall compute Kjnb and NH in the same way as the MME. 

NOTE: Since MME does not send the NH value to eNB in SI UE CONTEXT MODIFICATION REQUEST, the 
NH value associated with the NCC value one can not be used in the next X2 handover or the next intra-eNB 
handover. So for the next X2 handover or the next intra-eNB handover the horizontal key derivation (see Figure 
7.2.8.1-1) will apply. 

7.2.8.4 Key derivations during handovers 

7.2.8.4.1 Intra-eNB Handover 

When the eNB decides to perform an intra-eNB handover it shall derive KeNB* as in Annex A.5 using target PCI, its 
frequency EARFCN-DL, and either NH or the current KeNB depending on the following criteria: the eNB shall use the 
NH for deriving KeNB* if an unused {NH, NCC} pair is available in the eNB (this is referred to as a vertical key 
derivation), otherwise if no unused {NH, NCC} pair is available in the eNB, the eNB shall derive KeNB* from the 
current Kcnb (this is referred to as a horizontal key derivation). 

The eNB shall use the KeNB* as the KeNB after handover. The eNB shall send the NCC used for KeNB* derivation to UE 
in HO Command message. 

7.2.8.4.2 X2-handover 

As in intra-eNB handovers, for X2 handovers the source eNB shall perform a vertical key derivation in case it has an 
unused {NH,NCC} pair. The source eNB shall first compute KeNB* from target PCI, its frequency EARFCN-DL, and 
either from currently active KeNB in case of horizontal key derivation or from the NH in case of vertical key derivation 
as described in Annex A.5. The target eNB shall associate the NCC value received from source eNB with the KeNB- 

Next the source eNB shall forward the {KeNB*, NCC} pair to the target eNB. The target eNB shall include the received 
NCC into the prepared HO Command message, which is sent back to the source eNB in a transparent container and 
forwarded to the UE by source eNB. 

The target eNB shall use the received K^nb* directly as KeNB to be used with the UE. 
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When the target eNB has completed the handover signaling with the UE, it shall send a SI PATH SWITCH REQUEST 
to the MME. Upon reception of the SI PATH SWITCH REQUEST, the MME shall increase its locally kept NCC value 
by one and compute a new fresh NH by using the Kasme and its locally kept NH value as input to the function defined 
in Annex A.4. The MME shall then send the newly computed {NH, NCC} pair to the target eNB in the SI PATH 
SWITCH REQUEST ACKNOWLEDGE message. The target eNB shall store the received {NH, NCC} pair for further 
handovers and remove other existing unused stored {NH, NCC} pairs if any. 

NOTE: Because the path switch message is transmitted after the radio link handover, it can only be used to provide 
keying material for the next handover procedure and target eNB. Thus, for X2-handovers key separation 
happens only after two hops because the source eNB knows the target eNB keys. The target eNB can 
immediately initiate an intra-cell handover to take the new NH into use once the new NH has arrived in 
the SI PATH SWITCH REQUEST ACKNOWLEDGE. 

7.2.8.4.3 S1 -Handover 

When an SI -handover is performed, the source eNB shall not send any keys to the MME in the SI HANDOVER 
REQUIRED message. 

Upon reception of the HANDOVER REQUIRED message the source MME shall compute a fresh {NH, NCC} pair 
from its stored data using the function defined in Annex A.4. The source MME shall store that fresh pair and send it to 
the target MME in the S 10 FORWARD RELOCATION REQUEST message. The S 10 FORWARD RELOCATION 
REQUEST message shall in addition contain the Kasme that is currently used to compute {NH, NCC} pairs and its 
corresponding eKSI. 

The target MME shall store locally the {NH, NCC} pair received from the source MME. 

The target MME shall then send the received {NH, NCC} pair to the target eNB within the SI HANDOVER 
REQUEST. 

Upon receipt of the SI HANDOVER REQUEST from the target MME, the target eNB shall compute the KeNB to be 
used with the UE by performing the key derivation defined in Annex A.5 with the fresh{NH, NCC} pair in the SI 
HANDOVER REQUEST and the target PCI and its frequency EARFCN-DL. The target eNB shall include the NCC 
value from the received {NH, NCC} pair into the HO Command to the UE and remove any existing unused stored 
{NH, NCC} pairs. 

NOTE: The source MME may be the same as the target MME in the description in this subclause. If so the single 

MME performs the roles of both the source and target MME, i.e. the MME calculates and stores the fresh 
{NH, NCC} pair and sends this to the target eNB. 

7.2.8.4.4 UE handling 

The UE behaviour is the same regardless if the handover is SI, X2 or intra-eNB. 

If the NCC value the UE receieved in the HO Command message from target eNB via source eNB is equal to the NCC 
value associated with the currently active Kbnb, the UE shall dervie the KeNB* from the currently active KeNB and the 
target PCI and its frequency EARFCN-DL using the function defined in Annex A.5. 

If the UE received an NCC value that was different from the NCC associated with the currently active Kcnb, the UE 
shall first synchronize the locally kept NH parameter by computing the function defined in Annex A.4 iteratively (and 
increasing the NCC value until it matches the NCC value received from the source eNB via the HO command message. 
When the NCC values match, the UE shall compute the KeNB* from the synchronized NH parameter and the target PCI 
and its frequency EARFCN-DL using the function defined in Annex A.5. 

The UE shall use the KeNB* as the KeNB when communicating with the target eNB. 

7.2.9 Key-change-on-the fly 
7.2.9.1 General 

Key-change-on-the fly consists of re-keying or key-refresh. 
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Key refresh shall be possible for KeNB KRRc-enc^ KRRc-im . and Kup.enc and shall be initiated by the eNB when a PDCP 
COUNTS is about to be re-used with the same Radio Bearer identity and with the same K^nb- The procedure is 
described in clause 7.2.9.3. 

Re-keying shall be possible for the KeNB KRRc-enc, KRRc.im , and Kup-enc ■ This re-keying shall be initiated by the MME 
when an EPS AS security context different from the currently active one shall be activated. The procedures for doing 
this are described in clause 7.2.9.2. 

Re-keying shall be possible for Knas-emc and KNAs-im- Re-keying of Knasemc and KNAs-im shall be initiated by the MME 
when a NAS EPS security context different from the currently active one shall be activated. The procedures for doing 
this are described in clause 7.2.9.4. 

Re-keying of the entire EPS key hierarchy including Kasme shall be achieved by first re-keying K^sme- thenKNAs-enc and 
KNAs-im- followed by re-keying of the K^nb and derived keys. For NAS key change-on-on-the fly, activation of NAS 
keys is accomplished by a NAS SMC procedure. 

AS Key change on-the-fly is accomplished using a procedure based on intra-cell handover. The following AS key 
changes on-the-fly shall be possible: local KeNB refresh (performed when PDCP COUNTs are about to wrap around), 
KeNB re-keying performed after an AKA run, activation of a native context after handover from UTRAN or GERAN. 

7.2.9.2 KeNB re-keying 

The re-keying procedure is initiated by the MME after a successful AKA run with the UE to activate a partial native 
EPS security context, or to re-activate a non-current full native EPS security context after handover from GERAN or 
UTRAN according to subclauses 9.2.2.1 and 10.3.2. 

In case the procedure is initiated by the MME after a successful AKA run with the UE, the MME derives the new KeNB 
using the same key derivation function as is used for ECM-IDLE to ECM-CONNECTED state transitions (see Annex 
A) using the new Kasme and the NAS COUNT used in the NAS Security Mode Complete message. The K^nb is sent to 
the eNB after a successfully completed NAS SMC in a SI AP UE CONTEXT MODIFICATION REQUEST message 
triggering the eNB to perform the re-keying. The eNB runs the key-change-on-the-fly procedure with the UE. During 
this procedure the eNB shall indicate to the UE that a key change on-the-fly is taking place. The procedure used is 
based on an intra-cell handover, and hence the same KeNB derivation steps shall be taken as in a normal handover 
procedure. 

When the UE receives an indication that the procedure is a key change on-the-fly procedure, the UE shall use the Kasme 
from the current EPS NAS security context as the basis for KeNB derivations. 

NOTE 1 ; To perform a key change on-the-fly of the entire key hierarchy, the MME has to change the EPS NAS 
security context before changing the AS security context. 

If the UE has determined that the eKSI has changed, the UE shall derive a temporary K^nb by applying the same key 
derivation function as is used in ECM-IDLE to ECM-CONNECTED state transitions (see Annex A) using the NAS 
COUNT in the NAS Security Mode Complete message and the new Kasme as input. From this temporary K^nb the UE 
shall derive the K^nb* as normal (see Annex A). The eNB shall take the KgNB it received from the MME, which is equal 
to the temporary Ksnb, as basis for its KeNB* derivations. From this step onwards, the key derivations continue as in a 
normal handover. 

If the AS level re-keying fails, then the MME shall complete another NAS security mode procedure before initiating a 
new AS level re-keying. This ensures that a fresh KeNB is used. 

In case the re-keying procedure is initiated by the MME to re-activate a non-current full native EPS security context 
after handover from GERAN or UTRAN the same procedure as above applies. 

The NH parameter shall be handled according to the following rules: 

UE and MME shall use NH derived from old Kasme before the context modification is complete, i.e. for the UE 
when it sends the RRC Connection Reconfiguration Complete, and for the MME when it receives the UE 
CONTEXT MODIFICATION RESPONSE. In particular, the MME shall send an NH derived from old Kasme in 
the SlAP HANDOVER RESOURCE ALLOCATION, SIO FORWARD RELOCATION, and SlAP PATH 
SWITCH REQUEST ACKNOWLEDGE messages before the context modification is complete. 

The eNB shall delete any old NH upon completion of the context modification. 
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The UE and MME shall delete any old NH upon completion of the context modification. After the completion of 
the context modification, the UE and the MME shall derive any new NH parameters from the new KgNB and the 
new Kasme according to Annex A.4. 

In case the eNB has scheduled the UE for a handover when the re-keying message is received from the MME, the eNB 
and the UE shall perform the same key derivation steps as if it was an intra-cell handover with the sole purpose of a 
KeNB re-keying. 

NOTE 2: It is left to stage 3 specifications whether re-keying and inter-cell handover can be combined, and, if not, 
in which order these two procedures are executed. 

7.2.9.3 KeNB refresh 

This procedure is based on an intra-cell handover. The KeNB chaining that is performed during a handover ensures that 
the KeNB is re-freshed w.r.t. the RRC and UP COUNT after the procedure. 

7.2.9.4 NAS key re-keying 

After an AKA has taken place, new NAS keys from a new Kasme shall be derived, according to Annex A.7. 

To re-activate a non-current full native EPS security context after handover from GERAN or UTRAN, cf. clause 9.2.2 
B step 7, the UE and the MME take the NAS keys into use by running a NAS SMC procedure according to clause 
7.2.4.5. 

MME shall activate fresh NAS keys from an EPS AKA run or activate native security context with sufficiently low 
NAS COUNT values before the NAS uplink or downlink COUNT wraps around with the current security context. 

7.2.1 Rules on Concurrent Running of Security Procedures 

Concurrent runs of security procedures may, in certain situations, lead to mismatches between security contexts in the 
network and the UE. In order to avoid such mismatches, the following rules shall be adhered to: 

1 . MME shall not initiate any of the S 1 procedures Initial Context Setup or UE Context Modification including a 
new KeNB towards a UE if a NAS Security Mode Command procedure is ongoing with the UE. 

2. The MME shall not initiate a NAS Security Mode Command towards a UE if one of the S 1 procedures Initial 
Context Setup or UE Context Modification including a new KeNB is ongoing with the UE. 

3. When the MME has initiated a NAS SMC procedure in order to take a new Kasme into use, the MME shall 
continue to include AS security context parameters based on the old Kasme in the HANDOVER REQUEST or 
PATH SWITCH REQUEST ACKNOWLEDGE message, until the MME takes a KeNB derived from the new 
Kasme into use by means of an SI Initial Context Setup procedure or a UE Context Modification procedure. 

4. When the UE has received a NAS SMC message in order to take a new Kasme into use, the UE shall continue 
to use AS security context parameters based on the old Kasme in handover until the network indicates in an AS 
security mode command procedure or an RRCConnectionReconfiguration procedure to take a KeNB derived 
from the new Kasme into use. 

5. The source eNB shall reject an SI UE Context Modification Request when the eNB has initiated, but not yet 
completed, an inter-eNB handover. When a RRCConnectionReconfiguration procedure is ongoing the source 
eNB shall wait for the completion of this procedure before initiating any further handover procedure. 

6. When the MME has initiated a NAS SMC procedure in order to take a new Kasme into use and receives a 
request for an inter-MME handover from the serving eNB, the MME shall wait for the completion of the NAS 
SMC procedure before sending an SIO FORWARD RELOCATION message. 

7. When the MME has initiated a UE Context Modification procedure in order to take a new KeNB into use and 
receives a request for an inter-MME handover from the serving eNB, the MME shall wait for the (successful or 
unsuccessful) completion of the UE Context Modification procedure before sending an S 10 FORWARD 
RELOCATION message. 

8. When the MME has successfully performed a NAS SMC procedure taking a new Kasme into use, but has not 
yet successfully performed a UE Context Modification procedure, which takes a KeNB derived from the new 



£75/ 



3GPP TS 33.401 version 8.4.0 Release 8 41 ETSI TS 133 401 V8.4.0 (2009-07) 

Kasme into use, , the MME shall include both the old Kasme with the corresponding eKSI, NH, and NCC, and a 
full EPS NAS security context based on the new Kasme in the SIO FORWARD RELOCATION message. 

9. When an MME receives a S 10 FORWARD RELOCATION message including both the old Kasme with the 
corresponding eKSI, NH, and NCC, and a full EPS NAS security context based on the new Kasme the MME 
shall use the new Kasme in NAS procedures, but shall continue to include AS security context parameters 
based on the old Kasme in the HANDOVER REQUEST or PATH SWITCH REQUEST ACKNOWLEDGE 
message until the completion of a UE Context Modification procedure, which takes a K^nb derived from the 
new Kasme into use. 

7.3 UP security mechanisms 
7.3.1 UP confidentiality mecinanisms 

The user plane data is ciphered by the PDCP protocol between the UE and the eNB as specified in TS 36.323 [12].. 

The use and mode of operation of the 128-EEA algorithms are specified in Annex B. 

The input parameters to the 128-bit EEA algorithms as described in Annex B are an 128-bit cipher key Kupenc as KEY, a 
5-bit bearer identity BEARER which value is assigned as specified by TS 36.323 [12], the 1-bit direction of 
transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction 
dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT. 

7.4 RRC security meclnanisms 

7.4.1 RRC integrity meclnanisms 

RRC integrity protection shall be provided by the PDCP layer between UE and eNB and no layers below PDCP shall be 
integrity protected. 

The use and mode of operation of the 128 -EI A algorithms are specified in Annex B. 

The input parameters to the 128-bit EIA algorithms as described in Annex B are an 128-bit integrity key KRRcintas 
KEY, a 5-bit bearer identity BEARER which value is assigned as specified by TS 36.323 [12], the 1-bit direction of 
transmission DIRECTION and a bearer specific, time and direction dependent 32-bit input COUNT which corresponds 
to the 32-bit PDCP COUNT. 

The supervision of failed RRC integrity checks shall be performed both in the ME and the eNB. In case of failed 
integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message 
shall be discarded. This can happen on the eNB side or on the ME side. 

NOTE: This text does not imply that the concerned message is silently discarded. In fact, TS 36.331 [21] specifies 
that the UE shall trigger a recovery procedure upon detection of a failed RRC integrity check. When the 
cause for integrity protection failure is not a context mismatch, such as a key or HEN mismatch, the run 
of a recovery procedure unnecessarily adds load to the system. However, in the absence of a means for 
the UE to reliably detect the cause of an integrity protection failure and the fact that the only identified 
consequence of an active attack is limited to non-persistent DoS effects, priority was given to a procedure 
allowing recovery from the deadlock caused by a context mismatch. 

7.4.2 RRC confidentiality mechanisms 

RRC confidentiality protection is provided by the PDCP layer between UE and eNB. 

The use and mode of operation of the 128-EEA algorithms are specified in Annex B. 

The input parameters to the 128-bit EEA algorithms as described in Annex B are an 128-bit cipher Key KsRCenc as KEY, 
a 5-bit bearer identity BEARER which corresponds to the radio bearer identity, the 1-bit direction of transmission 
DIRECTION, the length of the keystream required LENGTH and a bearer specific, time and direction dependent 32-bit 
input COUNT which corresponds to the 32-bit PDCP COUNT. 
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7.4.3 KeNB* and Token Preparation for the RRCConnectionRe- 
establishment Procedure 

The KeNB* and token calculation at handover preparation are cell specific instead of eNB specific. At potential RRC 
Connection re-establishment (e.g, in handover failure case), the UE may select a cell different from the target cell to 
initiate the re-establishment procedure. To ensure that the UE RRCConnectionRe-establishment attempt is successful 
when the UE selects another cell under the control of the target eNB at handover preparation, the serving eNB could 
prepare multiple KeNB*s and tokens for mulitple cells which are under the control of the target eNB. 

The preparation of these cells includes sending security context containing KeNB*s and tokens for each cell to be 
prepared, as well as the corresponding NCC, the UE EPS security capabilities, and the security algorithms used in the 
source cell for computing the token, to the target eNB. The source eNB shall derive the KeNB*s as described in Annex 
A.5 based on the corresponding target ceir's physical cell ID and frequency EARFCN-DL. 

In order to calculate the token, the source eNB shall use the negotiated EIA-algorithm from the AS Security context 
from the source eNB with the following inputs: source C-RNTI, source PCI and target Cell-ID as defined by 
VarShortMAC-Input in TS 36.331 [21], where source PCI and source C-RNTI are associated with the cell the UE last 
had an active RRC connection with and target cell ID is the identity of the target cell where the 
RRCConnectionReestablishmentRequest is sent to. 

- KEY shall be set to K^RCintOf the source cell; 

- all BEARER bits shall be set to 1; 

- DIRECTION bit shall be set to 1; 

- all COUNT bits shall be set to 1. 

The token shall be the 16 least significant bits of the output of the used integrity algorithm. 

For X2 handover, the target eNB shall use these received multiple KeNB*s. But for SI handover, the target eNB discards 
the multiple KeNB*s received from the source eNB, and derives the KeNB*s as described in Annex A.5 based on the 
received fresh {NH, NCC} pair from MME for forward security purpose. 

When an RRCConnectionReestablishmentRequest is initiated by the UE, the RRCConnectionReestablishmentRequest 
shall contain the token corresponding to the cell the UE tries to reconnect to. This message is transmitted over SRBO 
and hence not integrity protected. 

The target eNB receiving the RRCConnectionReestablishmentRequest shall respond with an 
RRCConnectionReestablishment message containing the NCC received during the preparation phase if the token is 
valid, otherwise the target eNB shall reply with an RRCConnectionReestablishmentReject message. The 
RRCConnectionReestablishment and RRCConnectionReestablishmentReject messages are also sent on SRBO and 
hence not integrity protected. Next the target eNB and UE shall do the following: The UE shall firstly synchronize the 
locally kept NH parameter as defined in Annex A.4 if the received NCC value is different from the current NCC value 
in the UE itself Then the UE shall derive KeNB* as described in Annex A.5 based on the selected ceH"s physical cell ID 
and its frequency EARFCN-DL. The UE shall use this KeNB* as KeNB- The eNB uses the KeNB* corresponding to the 
selected cell as Kjnb- Then, UE and eNB shall derive and activate keys for integrity protection and verification from this 

KeNB- 

The UE shall respond with an RRCReestablishmentComplete on SRBl, integrity protected and ciphered using these new 
keys. The RRCConnectionReconfiguration procedure used to re-establish the remaining radio bearers shall only include 
integrity protected and ciphered messages. 

7.5 Signalling procedure for periodic local authentication 

The following procedure is used optionally by the eNB to periodically perform a local authentication. At the same time, 
the amount of data sent during the AS connection is periodically checked by the eNB and the UE for both up and down 
streams. If UE receives the Counter Check request, it shall respond with Counter Check Response message. 

The eNB is monitoring the PDCP COUNT values associated to each radio bearer. The procedure is triggered whenever 
any of these values reaches a critical checking value. The granularity of these checking values and the values 
themselves are defined by the visited network. All messages in the procedure are integrity protected. 



£75/ 



3GPP TS 33.401 version 8.4.0 Release 8 



43 



ETSI TS 133 401 V8.4.0 (2009-07) 



UE 



eNB 



1. Counter Check 



2. Counter Check Response 



3. Optionally release connection or 
report to MME or O&M server 



Figure 7.5-1 : eNB periodic local authentication procedure 

1. When a checking value is reached (e.g. the value in some fixed bit position in the hyperframe number is 
changed), a Counter Check message is sent by the eNB. The Counter Check message contains the most 
significant parts of the PDCP COUNT values (which reflect amount of data sent and received) from each active 
radio bearer. 

2. The UE compares the PDCP COUNT values received in the Counter Check message with the values of its radio 
bearers. Different UE PDCP COUNT values are included within the Counter Check Response message. 

3. If the eNB receives a counter check response message that does not contain any PDCP COUNT values, the 
procedure ends. If the eNB receives a counter check response that contains one or several PDCP COUNT values, 
the eNB may release the connection or report the difference of the PDCP COUNT values for the serving MME 
or O&M server for further traffic analysis for e.g. detecting the attacker. 
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8 Security mechanisms for non-access stratum 

signalling 

8.1 NAS integrity mechanisms 

Integrity protection for NAS signalling messages shall be provided as part of the NAS protocol. 

8.1 .1 NAS input parameters and mechanism 

Input parameters to the NAS 128-bit integrity algorithms as described in Annex B are an 128-bit integrity key KNASintas 
KEY an 5-bit bearer identity BEARER which shall equal the constant value 0x00, the direction of transmission 
DIRECTION, and a bearer specific, time and direction dependent 32-bit input COUNT which is constructed as 
follows: 

COUNT := 0x00 II NAS OVERFLOW II NAS SQN 

Where 

- the leftmost 8 bits are padding bits including all zeros. 

- NAS OVERFLOW is a 16-bit value which is incremented each time the NAS SQN is incremented from the maximum 
value. 

- NAS SQN is the 8-bit sequence number carried within each NAS message. 

NOTE: The BEARER identity is not necessary since there is only one NAS signalling connection per pair of 

MME and UE, but is included as a constant value so that the input parameters for AS and NAS will be the 
same, which simplifies specification and implementation work. 

The use and mode of operation of the 128 -bit integrity algorithms are specified in Annex B. 

The supervision of failed NAS integrity checks shall be performed both in the ME and the MME. In case of failed 
integrity check (i.e. faulty or missing NAS-MAC) is detected after the start of NAS integrity protection, the concerned 
message shall be discarded except for some NAS messages specified in TS 24.301 [9]. For those exceptions the MME 
shall take the actions specified in TS 24.301 [9] when receiving a NAS message with faulty or missing NAS-MAC. 
Discarding NAS messages can happen on the MME side or on the ME side. 

8.1 .2 NAS integrity activation 

NAS integrity shall be activated with the help of the NAS SMC procedure immediately after successful authentication. 
NAS integrity stays activated until the EPS security context is deleted. The EPS security context may only be deleted if 
UE is in EMM-DEREGISTERED. While the EPS security context exists, all NAS messages shall be integrity protected. 
In particular the NAS service request shall always be integrity protected and the NAS attach request message shall be 
integrity protected if the EPS security context is not deleted while UE is in EMM-DEREGISTERED. The length of the 
NAS-MAC is 32 bit. The full NAS-MAC shall be appended to all integrity protected messages except for the NAS 
service request. Only the 16 least significant bits of the 32 bit NAS-MAC shall be appended to the NAS service request 
message. 

The use and mode of operation of the 128-EIA algorithms are specified in Annex B. 

8.2 NAS confidentiality mecinanisms 

The input parameters for the NAS 128-bit ciphering algorithms shall be the same as the ones used for NAS integrity 
protection as described in clause 8.1, with the exception that a different key, KtMASenc^ is used as KEY, and there is an 
additional input parameter, namely the length of the key stream to be generated by the encryption algorithms. 

The use and mode of operation of the 128-bit ciphering algorithms are specified in Annex B. 
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9 Security interworking between E-UTRAN and 

UTRAN 

9.1 Idle mode procedures 

9.1 .1 Idle mode procedures in UTRAN 

This subclause covers both the cases of idle mode mobility from E-UTRAN to UTRAN and of Idle Mode Signaling 
Reduction (ISR), as defined in TS 23.401 [2]. 

NOTE 1: TS 23.401 states conditions under which a valid P-TMSI or a P-TMSI that is mapped from a valid GUTI 
('mapped GUTI') is inserted in the Information Element 'old P-TMSI' in the Routing Area Update 
Request. It depends on the old P-TMSI which security context can be taken into use after completion of 
the Routing Area Update procedure. 

Use of an existingUMTS securitycontext 

If the UE sends the RAU Request with the "old P-TMSI" Information Element including a valid P-TMSI it shall also 
include the KSI relating to this P-TMSI. This KSI is associated with the UMTS security context stored on the UE, and it 
indicates this fact to the SGSN. In this case the UE shall include P-TMSI signature into the RAU Request if a P-TMSI 
signature was assigned by the old SGSN. If the network does not have a valid security context for this KSI it shall run 
AKA. In case of an SGSN change keys from the old SGSN shall overwrite keys in the new SGSN if any. 

NOTE 2: if the UE has a valid UMTS security context then this context is stored on the USIM according to TS 

33.102 [4]. 

Mapping of EPS security context to UMTS security context 

If the UE sends the RAU Request with the "old P-TMSI" Information Element including mapped GUTI it shall also 
include the KSI equal to the value of the eKSI associated with the current EPS security context (cf clause 3). The UE 
shall include a truncated NAS -token, as defined in this clause further below, into the P-TMSI signature IE. The MME 
shall transfer UE's UTRAN and GERAN security capabiUties and CK' II IK' with KSI equal to the value of the eKSI 
associated with the current EPS security context to SGSN with Context Response/SGSN Context Response message. 
The MME and UE shall derive CK' and IK' from the Kasme and the NAS downlink COUNT value corresponding to the 
truncated NAS-token received by the MME from SGSN as specified in Annex A. Keys CK' and IK' and KSI sent from 
the MME shall replace the keys and KSI in the target SGSN if any. Keys CK' and IK' and the KSI shall replace the 
currently stored values on the USIM. START shall be reset to on USIM. 

NOTE 3: The new derived security context (including CK", IK" and START value) replacing the old stored values 
in the USIM is for allowing to reuse the derived security context without invoking the authentication 
procedure in the subsequent connection set-ups , and also for avoiding that one KSI indicates to two 
different key sets and consequently leads to security context desynchronization. 

NOTE 4: An operator concerned about the security of keys received from another operator may want to enforce a 
policy in SGSN to run a UMTS AKA as soon as possible after the run of an idle mode mobility 
procedure. An example of ensuring this is the deletion of the mapped UMTS security context in the 
SGSN after the completion of the idle mode mobility procedure. 

SGSN shall include the allowed security algorithm and transfer them to RNC. An SMC shall be sent to the UE 
containing the selected algorithms. 

The X bits available in the P-TMSI signature field (at minimum 16 bits) shall be filled with the truncated NAS-token, 
which is defined as the x least significant bits of the NAS-token. 

The NAS-token is derived as specified in Annex A.9. 

SGSN shall forward the P-TMSI signature including the truncated NAS token to the old MME, which compares the 
received bits of the truncated NAS-token with the corresponding bits of a NAS-token generated in the MME, for the 
UE identified within the context request. If they match, the context request message is authenticated and authorized and 
MME shall provide the needed information for the SGSN. Old MME shall respond with an appropriate error cause if it 
does not match the value stored in the old MME. This should initiate the security functions in the new SGSN. 
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To avoid possible race condition problems, the MME shall compare the received truncated NAS-token with the x least 
significant bits of NAS-tokens generated from the current NAS downlink COUNT value down to current NAS 
COUNT-L downUnk values, i.e. the interval [current NAS downlink COUNT - L, current NAS downlink COUNT]. A 
suitable value for the parameter L can be configured by the network operator. MME shall not accept the same NAS- 
token for the same UE twice except in retransmission cases happening for the same mobility event. 

9.1 .2 Idle mode procedures in E-UTRAN 

This subclause covers both the cases of idle mode mobility from UTRAN to E-UTRAN and of Idle Mode Signaling 
Reduction, as defined in TS 23.401 [2]. 

The TAU Request and ATTACH Request message shall include the UE security capabilities. The MME shall store 
these UE security capabilities for future use. The MME shall not make use of any UE security capabilities received 
from the SGSN. 

NOTE 1: TS 23.401 states conditions under which a valid GUTI or a GUTI that is mapped from a valid P-TMSI is 
inserted in the Information Element 'old GUTI' in the Tracking Area Update Request.The value in the 
'old' GUTI IE informs the MME, which SGSN/MME to fetch the UE context from. 

Case 1: P-TMSI not included in 'old GUTI' IE in TAU Request 

The UE shall use the current EPS security context to protect the TAU Request and include the corresponding GUTI and 
eKSI value. The TAU Request shall be integrity-protected, but not confidentiality-protected. UE shall use the current 
EPS security context algorithms to protect the TAU Request message. 

Case 2: Mapped P-TMSI included in 'old GUTI' IE in TAU Request 

If the UE sends a TAU Request to the MME, and was previously connected to UTRAN where the SGSN assigned a P- 
TMSI signature to the UE, the UE shall include that P-TMSI signature in the TAU Request. 

If the MME received a P-TMSI signature from the UE, the MME shall include that P-TMSI signature in the Context 
Request message sent to the SGSN. The SGSN shall transfer CK II IK to MME in the Context Response/SGSN Context 
Response message. MME shall derive K'ASMEfrom CK II IK as described in Annex A. In case the MM context in the 
Context Response/SGSN Context Response indicates GSM security mode, the MME shall abort the procedure. 

MME shall select security algorithms, based on the UE EPS security capabilities received in the TAU request, and 
indicate them to the UE by e.g. with NAS SMC. 

If the UE has a current security context, the UE shall use this security context to protect the TAU Request. If not the UE 
shall send the TAU Request unprotected. 

In both cases 2. 1 or 2.2, the UE shall include in the TAU Request: 

the KSI with corresponding P-TMSI and old RAI to point to the right source SGSN and key set. there. This 
allows the UE and MME to generate the mapped security context, as described in Case 2.2 below, if current EPS 
security context is not available in the UE and network. The KSI shall correspond to the set of keys most 
recently generated (either by a successful AKA run or mapping from an EPS security context). 

a 32bit NONCEue (see clause A. 11 for requirements on the randomness of NONCEue)- 



NOTE 2: The current EPS security context may be of type "mapped", and hence the value of the eKSI be of type 
"KSIsGSN "• This value of KSIsgsn may be different from the KSI pointing to the set of keys most recently 
generated in UTRAN as an AKA run may have happened in UTRAN after the current mapped EPS 
security context indicated by the eKSI with the value KSIsgsn was generated 

Case 2.1: Current EPS security context in the UE 

The UE shall include the corresponding GUTI and eKSI value in the TAU Request. The TAU Request shall be 
integrity-protected, but not confidentiality-protected. The UE shall use the current security context algorithms to protect 
the TAU Request message. 
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NOTE 3: Case 2.1 relates to the following scenario: a UE established a current EPS security context during a 
previous visit to EPS, then moves to UTRAN/GERAN from E-UTRAN and storing the current EPS 
security context. When the UE moves back to E-UTRAN there is a current EPS security context. 

In case MME has the current security context it shall verify the TAU Request message. If it is successful, the MME 
shall reply with a TAU Accept message protected with the security context. In case the TAU Request had the active flag 
set or there is pending downlink UP data, Konb is calculated as described in clause 7.2.7.. 

If the MME changes the algorithms, they shall be indicated to the UE in an integrity protected NAS SMC, which shall 
also include the UE security capabilities and KSIasme- This message shall not be ciphered. UE shall reply with integrity 
protected NAS SMC COMPLETE protected based on the new selected algorithms and Kasme- 

If the USIM supports EMM parameters storage then the new native EPS NAS security context shall be stored on the 
USIM. 

If the MME does not have the security context indicated by the UE in the TAU request, then Case 2.2 below applies. 

Case 2.2: Creating a Mapped EPS security context 

If a current EPS security context is not available in the UE, the UE shall send the TAU request unprotected. 

If the MME does not have the context indicated by the UE in the TAU request, or the TAU request was received 
unprotected, the MME shall create a new mapped security context. In this case, the MME shall generate a 32bit 
NONCEmme (see clause A. 10 for requirements on the randomness of NONCEmme). and use the received NONCEue 
with the NONCEmme to generate a fresh mapped K'asme from CK and IK, where CK, IK were identified by the KSI and 
P-TMSI in the TAU Request. See Annex A. 11 for more information on how to derive the fresh K'asme- If the TAU 
Request had the active flag set or there is pending downlink UP data, the uplink NAS Count which is set to zero shall be 
used to derive the KeNB in MME and UE as specified in Annex A. MME shall deliver the Ke^B to the target eNB on the 
SI interface. The uplink and downlink NAS COUNT for mapped security context shall be set to start value (i.e., 0) 
when new mapped security context is created in UE and MME. 

The selected algorithms and the KSIsgsn shall be indicated to the UE in an integrity protected NAS SMC COMMAND 
message protected with NAS keys based on K'asme^ which shall also include the UE security capabilities, NONCEue, 
and NONCEmme- The UE shall generate a mapped K'asme from CK and IK in the same way as the MME. The UE shall 
compare the received NONCEue with the NONCEue sent, and if the NONCEue was modified in the TAU request, then 
the UE shall return NAS security mode reject message. If the received NONCEue is the same as the NONCEue sent and 
the integrity check succeeds, then UE shall reply with integrity protected and ciphered NAS SMC COMPLETE 
message based on the selected algorithms and NAS keys based on K'asme so that the MME can be sure that they were 
not modified in the TAU Request message by an outsider. 

TAU Accept shall be protected using the NAS keys based on the fresh K'asme- 

9.2 Handover 

9.2.1 From E-UTRAN to UTRAN 

NAS and AS security shall always be activated before handover from E-UTRAN to UTRAN can take place. 
Consequently the source system in the handover shall always send a key set to the target system during handover. The 
security policy of the target PLMN determines the selected algorithms to be used within the UTRAN HO command. UE 
and MME shall derive a confidentiality key CK', and an integrity key IK' from the Kasme and the NAS downlink 
COUNT value of the current security context with the help of a one-way key derivation function KDF as specified in 
Annex A. 

Whether ciphering is considered active in the target UTRAN after handover from E-UTRAN shall be determined 
according to the principles for handover to UTRAN in TS 25.331 [24]. 

UE and MME shall assign the value of eKSI to KSI. MME shall transfer CK' II IK' with KSI to SGSN. The target 
SGSN shall replace all stored parameters CK, IK, KSI, if any, with CK' , IK', KSI received from the MME. The UE 
shall replace all stored parameters CK, IK, KSI, if any, with CK' , IK', KSI in both ME and USIM. START shall be 
reset to 0. For the definition of the Key Derivation Function see Annex A. 
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NOTE 1: The new derived security conterxt (including CK", IK" and START value) replacing the stored values in 
the USIM is for allowing to reuse the derived security context without invoking the authentication 
procedure in subsequent connection set-ups, and also for avoiding that one KSI value indicates to two 
different key sets and consequently leads to security context desynchronization. 

NOTE 2: An operator concerned about the security of keys received from an E-UTRAN of another operator may 
want to enforce a policy in SGSN to run a UMTS AKA as soon as possible after the handover. One 
example of ensuring this is the deletion of the mapped UMTS security context in the SGSN after the UE 
has left active state. 

MME shall also provide at least the 4 LSB of the current NAS downlink COUNT value to the source eNB, which then 
shall include the bits to the MobilityFromE-UTRANCommand to the UE. 

MME shall transfer the UE security capabilties to the SGSN. The selection of the algorithms in the target system 
proceeds as described in TS 33.102 [4] for UTRAN. 

9.2.2 From UTRAN to E-UTRAN 
9.2.2.1 Procedure 

The procedure for handover from UTRAN to E-UTRAN, as far as relevant for security, proceeds in the following two 

consecutive steps: 

A) Handover signalling using the mapped security context (cf. also Figure 9.2.2.1-1); 

B) Subsequent NAS signalling to determine whether a native context is taken in use (not shown in Figure). 

The activation of NAS and AS security in E-UTRAN, and selection of the key set from the source system for the 
handover shall be according to following principles: 

i) As described for inter-SGSN PS handover cases in TS 33.102 [4], the source SGSN shall select the key set most 
recently generated (either by a successful AKA run or mapping from an EPS security context) and transfer this key set 
to the MME in the Forward Relocation Request. 

NOTE x: The MME is considered as a target SGSN in case of Gn/Gp interface, 
ii) Activation of AS security (for details cf. TS 36.331 [21]): 

The E-UTRAN HO command received at the UE shall activate AS security. 

The HO Complete received at the eNB shall activate AS security, 
iii) Activation of NAS security (for details cf. TS 24.301 [9]): 

The E-UTRAN HO command received at the UE shall activate NAS security. 

The HO Notify received at the MME shall activate NAS security. In case the MME does not have the UE security 
capabilities stored from a previous visit, then no NAS message shall be sent or accepted by the MME other than 
a TAU request before a successful check of the UE security capabilities in the TAU request was performed by 
the MME. 

iv) Both AS and NAS ciphering and integrity protection algorithms shall be selected according to the policy of the 
target PLMN. 

The above four principles consequentially always activate ciphering (potentially NULL ciphering) in E-UTRAN even if 
it was not active in the source system. 
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Figure 9.2.2.1-1 : Handover from UTRAN to E-UTRAN 

A) Handover signalling in case of successful handover 

The RNC shall send a Relocation Request message to the SGSN. This message does not contain any security-relevant 
parameters. 

1. The SGSN shall transfer MM context (including CK and IK (or the Kc), KSI and the UE security capabihties) to 

MME in the Forward relocation request message. In case the MM context in the Forward relocation request 
message indicates GSM security mode(i.e., it contains a Kc), the MME shall abort the procedure. The UE 
security capabilities, including the UE EPS security capabilities, were sent by the UE to the SGSN via the MS 
Network Capability IE, that is extended to include also UE EPS security capabilities, in Attach Request and 
RAU Request. It is possible that an SGSN does not forward the UE EPS security capabilities to the MME. 
When the MME does not receive UE EPS security capabilities from the SGSN, the MME shall assume that the 
following default set of EPS security algorithms is supported by the UE (and shall set the UE EPS security 
capabilities in the mapped EPS NAS security context according to this default set): 

- EEAO, 128-EEAl and 128-EEA2 for NAS signalling ciphering, RRC signalling ciphering and UP ciphering; 

- 128-EIAl and 128-EIA2 for NAS signalling integrity protection and RRC signalling integrity protection. 

NOTE 0: Subclauses 5.1.3.2 and 5.1.4.2 of this specification mandate the UE to support the default set of EPS 
security algorithms, so, for the Rel-8 version of this specification, the default set of EPS security 
algorithms includes all security algorithms standardised for EPS. The notion of default set of EPS security 
algorithms is introduced here in order to make this specification future-proof as more security algorithms 
may be standardised for EPS in future releases. 

2. The MME shall create a NONCEmme to be used in the K'asme derivation (see clause A. 10 for requirements on 
the randomness of NONCEmme) . MME shall derive K'asme from CK and IK with the help of a one-way key 
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derivation function as defined in Annex A and associate it with a Key Set Identifier KSIsgsn- The value field of 
the KSIsgsn shall be derived by assigning the KSI corresponding to the set of keys most recently generated 
(either by a successful AKA run or mapping from an EPS security context). MME shall derive the NAS keys 
and KgNB from K'asme- The uplink and downlink NAS COUNT values for the mapped security context shall be 
reset to start value (i.e. 0) in the UE and the MME. 

3. MME shall select the NAS security algorithms, MME shall include KSIsgsn, NONCEmme, the selected NAS 

security algorithms in the NAS Security Transparent Container IE of S 1 HO Request message to the target 
eNB. MME further shall include K^nb and the UE EPS security capabilities, either the capabilities received 
from the SGSN or, in the absence of these, the default set of EPS security algorithms, in the S 1 HO Request 
message to the target eNB. 

4. The target eNB shall select the RRC and UP algorithms based on the UE EPS Security Capabilities. The target 

eNB shall create a transparent container (RRCConnectionReconfiguration) including the selected RRC, UP 
algorithms and the NAS Security Transparent Container IE, and send it in the S 1 HO Request Ack message 
towards the MME. 

NOTE 1: This transparent container is not protected by the target eNB. 

5. MME shall include the transparent container received from the target eNB in the FW Relocation Response 

messgage sent to SGSN. 

6. SGSN shall include the transparent container in the relocation command sent to the RNC. 

7. The RNC shall include the transparent container in the UTRAN HO command sent to the UE. 

NOTE 2: The UTRAN HO command is integrity protected and optionally ciphered as specified by TS 33.102 [4]. 

8. The UE shall derive K'asme in the same way the MME did in step 2, associate it with KSIsgsn and derive NAS, 

RRC and UP keys accordingly. The UE shall send a RRCConnectionReconfiguration Complete messages to 
the eNB. The uplink and downlink NAS COUNT values for the mapped context shall be set to start value (i.e. 
0) in the UE and the MME. 

9. The mapped EPS security context shall become the current (cf. subclause 3.1) EPS security context at AS and 

NAS level and overwrite any existing current mapped EPS security context. If the current security context is of 
type native, then it shall become the non-current native security context and overwrite any exisiting non- 
current security context. The HO Complete messages and all following AS messages in E-UTRAN shall be 
ciphered and integrity protected according to the policy of the target PLMN. 

B) Subsequent NAS signalling 

In order to prevent that successful bidding down on the UE security capabilities in a previous RAT have an effect on the 
selection of EPS security algorithm for NAS and AS, the UE security capabilities shall be included in the TAU request 
after IRAT-HO and be verified by the MME. 

NOTE 3: Any TAU request following the handover will be integrity protected. Details are described in subclause 

9.2.2.1 

In any case UE security capability information received from the UE overwrites any capabilities received with the 
context transfer as specified in TS 23.401 [2]. 

It can happen that the MME receives UE security capabilities in the TAU Request that contains an algorithm with 
higher priority (according to the priority list stored in the MME) than any of the algorithms the MME received from the 
source SGSN. It can also happen that the MME uses the default set of EPS security algorithms for the UE according to 
A) step 1 above, and the TAU Request contains an algorithm with higher priority (according to the priority list stored in 
the MME) than the default set. If any of these cases happen, the MME shall run a NAS security mode command 
procedure to change the NAS algorithms according to subclause 7.2.4.4 and a SI CONTEXT MODIFICATION 
procedure to inform the eNB about the correct UE EPS security capabilities and trigger a change of AS algorithms. 

1 . If the MME has native security context for the UE and does not receive a TAU request within a certain period 
after the HO it shall assume that UE and MME share a native security context. 

NOTE 4: A TAU procedure following handover from UTRAN to E-UTRAN is mandatory if the Tracking Area has 
changed, but optional otherwise, cf. TS 23 .401 [2]. 
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2. When the UE sends a TAU request it shall protect the request using the mapped EPS security context 
identified by KSIsgsn- The UE shall also include KSIasme in the TAU request if and only if it has native EPS 
security context. The KSIasme shall be accompanied by a GUTI. When the MME receives a TAU request with 
a KSIasme and GUTI corresponding to the native EPS security context stored on that MME it knows that UE 
and MME share a native security context. 

3. Void. 
NOTE 5: Void. 

4. When the MME receives a TAU request without a KSIasme it shall delete any native EPS security context for 
any GUTI it may have for the user who sent the TAU request. 

5. If the MME shares the native EPS security context indexed by the KSIasme and GUTI from the TAU Request 
with the UE, the MME may run a NAS security mode command procedure with the UE to activate the native 
EPS NAS security context according to clause 7.2.9.4. The MME may in addition change the Kj-nb on the fly 
according to clause 7.2.9.2). In case the GUTI received in the TAU Request message pointed to a different 
MME, the allocation of a new GUTI, replacing the received GUTI, and the association of this new GUTI with 
KSIasme is required. 

6. Void. 

NOTE 6: The TAU Request is integrity protected with the mapped EPSsecurity context even if the UE and the 
MME share a native EPSsecurity context since the UE cannot know for sure if the MME still has the 
native EPS security context at the time of sending the TAU Request. 

7. When the MME knows, after having completed the TAU procedure in the preceding steps, that it shares a 
native EPS security context with the UE, the MME may (depending on configured policy and if the MME did 
not do it already in step 5) activate this native EPS security context. This activation may occur in three ways: 

a. During ECM-CONNECTED state: the MME shall initiate a key change on the fly procedure 
according to subclause 7.2.9 for the entire EPS key hierarchy. 

b. After the next transition to ECM-IDLE state following the handover from UTRAN: Upon receiving 
the first message from the UE after the UE has gone to ECM-IDLE state the MME shall use the 
procedures defined in subclauses 7.2.4.4 and 7.2.4.5 to activate the native EPS security context. 

c. At the next transition to EMM-DEREGISTERED (see clause 7.2.5.1). 

8. If native EPS security context has been established, then the UE and the MME shall delete the mapped EPS 
security context and set the native EPS security context to the current EPS security context. 

NOTE 7: The run of an NAS SMC procedures ensures that the uplink NAS COUNT has increased since the last 
time a K^nb was derived from the Kasme- 

NOTE 8: For the handling of native and mapped contexts after a state transition to EMM-DEREGISTERED cf. 

subclause 7.2.5.1. 

9.2.2.2 Derivation of NAS keys and KgNB during Handover from UTRAN to E-UTRAN 

MME and UE shall derive the NAS keys from the mapped key K'asme as specified in Annex A. 

MME and UE shall derive KgNB from K'asme as follows: 

The MME sets NAS COUNT equal to zero and uses it with the mapped key K'asme to derive KeNB by applying the KDF 
defined in Annex A for IDLE to CONNECTED transition. 

9.3 Recommendations on AKA at IRAT-mobility to E-UTRAN 

After a handover from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an AKA and perform a 
key change on-the-fly of the entire key hierarchy as soon as possible after the handover if there is no native security 
context in E-UTRAN. 
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When a UE moves in IDLE mode from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an 
AKA if there is no native security context in E-UTRAN, either after the TAU procedure that estabhshes an EPS 
security context in the MME and UE, or when the UE transits into ECM-CONNECTED state. 
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10 Security interworking between E-UTRAN and 
GERAN 

10.1 General 

An SGSN supporting interworking between E-UTRAN and GERAN is capable of handling UMTS security contexts 
and supports the key conversion function c3 specified in TS 33. 102 [4]. Furthermore, as a consequence of the UE 
being able to access EPS, the user has a USIM, and the ME and the HSS are UMTS-capable. Hence, UMTS AKA is 
used when the UE is authenticated even when attached to GERAN, and UMTS security contexts are available. The 
security procedures for interworking between E-UTRAN and GERAN are therefore quite similar to those between E- 
UTRAN and UTRAN. 

10.2 Idle mode procedures 

10.2.1 Idle mode procedures in GERAN 

This subclause covers both the cases of idle mode mobility from E-UTRAN to GERAN and of Idle Mode Signaling 
Reduction, as defined in TS 23.401 [2]. 

As the SGSN is capable of handling UMTS security contexts clause 9.1.1 applies here with the following changes 

the SGSN and UE shall derive Kc from CK' and IK' with the help of the key conversion function c3 of TS 33. 102; 

SGSN shall select the encryption algorithm to use in GERAN. 

1 0.2.2 Idle mode procedures in E-UTRAN 

This subclause covers both the cases of idle mode mobility from GERAN to E-UTRAN and of Idle Mode Signaling 
Reduction, as defined in TS 23.401 [2]. 

As the SGSN shares a UMTS security context with the UE clause 9.1.2 applies here without changes. 

10.3 Handover 

1 0.3.1 From E-UTRAN to GERAN 

As the SGSN is capable of handling UMTS security contexts clause 9. 2.1 applies here with the following changes: 

SGSN and UE shall derive Kc from CK' and IK' with the help of the key conversion function c3 of TS 33.102. 

SGSN shall select the encryption algorithm to use in GERAN after handover. 

Whether ciphering is considered active in the target GERAN after handover from E-UTRAN shall be determined 
according to the principles for handover to GERAN in TS 44.060 [25]. 

1 0.3.2 From GERAN to E-UTRAN 

10.3.2.1 Procedures 

As the SGSN shares a UMTS security context with the UE clause 9.2.2 applies here without changes. 
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1 0.4 Recommendations on AKA at IRAT-mobility to E-UTRAN 

See recommendation provided by subclause 9.3. 

1 1 Network Domain Control Plane protection 

The protection of IP based control plane signalling for EPS and E-UTRAN shall be done according to TS 33.210 [5]. 

NOTE 1: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection 
according to TS 33.210 [5]. 

In order to protect the S 1 and X2 control plane, it is required to implement IPsec ESP according to RFC 4303 [7] as 
specified by TS 33.210 [5]. For both Sl-MME and X2-C, IKEv2 certificates based authentication according to TS 
33.310 [6] shall be implemented. For Sl-MME and X2-C, tunnel mode IPsec is mandatory to implement on the eNB. 
On the core network side a SEG may be used to terminate the IPsec tunnel. 

Transport mode IPsec is optional for implementation on the X2-C and Sl-MME. 

NOTE 2: Transport mode can be used for reducing the protocol overhead added by IPsec. 

12 Backhaul link user plane protection 

The protection of user plane data between the eNB and the UE by user specific security associations is covered by 
clause 5.1.3 and 5.1.4. 

In order to protect the S 1 and X2 user plane as required by clause 5.3.3, it is required to implement IPsec ESP according 
to RFC 4303 [7] as profiled by TS 33.210 [5], with confidentiality, integrity and replay protection. 

On the X2-U and Sl-U, transport mode IPsec is optional for implementation. 

NOTE 1 : Transport mode can be used for reducing the protocol overhead added by IPsec. 

Tunnel mode IPsec is mandatory to implement on the eNB for X2-U and Sl-U. On the core network side a SEG may be 
used to terminate the IPsec tunnel.. 

For both S 1 and X2 user plane, IKEv2 with certificates based authentication shall be implemented. The certificates shall 
be implemented according to the profile described by TS 33.310 [6]. IKEv2 shall be implemented conforming to the 
IKEv2 profile described in TS 33.310 [6] 

NOTE 2: In case S 1 and X2 user plane interfaces are trusted (e.g. physically protected), the use of IPsec/IKEv2 
based protection is not needed. 
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13 Management plane protection over the S1 interface 

Clause 5.3.2 requires that eNB setup and configuration traffic, i.e. the management plane, to be protected between the 
EPS core and the eNB. This traffic is typically carried over the same backhaul link as the SI interface. Therefore, the 
protection mechanism defined for Sl-MME and Sl-U may be re-used for SI management plane, Sl-M. 

In this case and in order to achieve such protection, it is required to implement IPsec ESP according to RFC 4303 [7] as 
profiled by TS 33.210 [5], with confidentiality, integrity and replay protection. 

Tunnel mode IPsec is mandatory to implement on the eNB for supporting the S 1 management plane. On the core 
network side a SEG may be used to terminate the IPsec tunnel. If no SEG is used, the IPsec tunnel may be terminated in 
the element manager. 

For the SI management plane, IKEv2 with certificates based authentication shall be implemented on the eNB. The 
certificates shall be implemented according to the profile described by TS 33.310 [6]. IKEv2 shall be implemented 
conforming to the IKEv2 profile described in TS 33.310 [6] 

NOTE 1: X2 does not carry management plane traffic. 

NOTE 2: In case the S 1 management plane interfaces are trusted (e.g. physically protected), the use of IPsec/IKEv2 
based protection is not needed 
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14 SRVCC between E-UTRAN and Circuit Switched 
UTRAN/GERAN 

14.1 From E-UTRAN to Circuit Switched UTRAN/GERAN 

Single Radio Voice Call Continuity (SRVCC) is specified in 3GPP TS 23.216 [22]. 

The MME and the UE shall derive a confidentiality key CKsrvcc^ and an integrity key IKsrvcc from Kasme and the 
NAS downlink COUNT with the help of a one-way key derivation function KDF as specified in Annex A. 

The KDF returns a 256-bit output, where the 128 most significant bits are identified with CKsrvcc and the 128 least 
significant bits are identified with IKsrvcc- 

The MME shall also provide the 4 LSB of the current NAS downlink COUNT value to the source eNB, which then 
includes the bits to the HO Command to the UE. 

UE and MME shall assign the value of eKSI to KSI. MME shall transfer CKsrvcc, IKsrvcc with KSI and the UE 
security capability to the enhanced MSC server. The enhanced MSC server shall replace the stored parameters CK, IK, 
KSI, if any, with CKsrvcc, IKsrvcc, KSI received from the MME. The UE shall replace the stored parameters CK, IK, 
KSI, if any, with CKsrvcc, IKsrvcc, KSI in both ME and USIM. START shall be reset to 0. 

NOTE 1 : The new derived security context (including CKsrvcc, IKsrvcc , KSI and START value) replacing the 
stored values in the USIM is for allowing to reuse the derived security context without invoking the 
authentication procedure in subsequent connection set-ups, and also for avoiding that one KSI value 
indicates to two different key sets and consequently leads to security context desynchronization. 

NOTE 2: An operator concerned about the security of keys received from an E-UTRAN of another operator may 
want to enforce a policy in the enhanced MSC server to run a UMTS AKA as soon as possible after the 
handover. One example of ensuring this is the deletion of the mapped UMTS security context in the the 
enhanced MSC server after the UE has left active state. 

If the SRVCC is from E-UTRAN to GERAN, the enhanced MSC server and the UE shall derive Kc from CKsrvcc and 
IKsrvcc with the help of the key conversion function c3 as specified in TS 33.102 [4]. The UE and the enhanced MSC 
Server shall assign the value of eKSI to CKSN. 

NOTE: Non-voice bearers may be handed over during the SRVCC handover operation. Key derivation for non- 
voice bearers is specified in clause 9 of the present specification. 
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Annex A (normative): 
Key derivation functions 

A.1 KDF interface and input parameter construction 
A.1.1 General 

The input parameters and their lengths shall be concatenated into a string S as follows: 

1 . The length of each input parameter encoding measured in octets shall be encoded into a two octets long string: 

a) express the number of octets in input parameter Pi as a number k in the range [0, 65535]; 

b) Li is then a two-octet representation of the number k written in base 2 and using the bit ordering specified in 
clause 3.4. Any unused most significant bits of Li shall be set to zero. 

EXAMPLE: If Pi contains 258 octets then Li will be the two-octet bit-string (0000000100000010)2, or 0x01 
0x02 in hex notation. 

2. Given a non-negative integer j expressing the value to be encoded in Pi, Pi shall be formed by writing j in base 2. 
The least significant bit of Pi shall be equal to the least significant bit of j, i.e., according to clause 3.4 of this 
specification. Any unused most significant bits of Pi shall be set to zero to meet the octet length prescribed by Li. 

EXAMPLE: If Pi is the integer value 259 and the the length of parameter Pi is two octets. Pi consists of the bit- 
pattern (000000010000001 1)2 or 0x01 0x03 in hex representation. 

3. String S shall be constructed from n input parameters as follows: 

S = EC II PO II LO II PI II LI II P2 II L2 II P3 II L3 II... II Pn II Ln 

where: 

EC is single octet used to distinguish between different instances of the algorithm, 

PO ... Pn are the n input parameter encodings, and 

LO ... Ln are the two-octet representations of the length of the corresponding input parameter encodings PO ... 
Pn. 

4. The final output, i.e. the derived key is equal to the KDE computed on the string S using the key Key. The 
present document defines the following KDE: 

derived key = HMAC-SHA-256 (Key, S), 

as specified in [10] and [11], which has the KDE identity 1. 

All key derivations for EPS shall be performed using the key derivation function (KDE) specified in this Annex. This 
clause specifies the set of input strings. Si, to the KDE (which are input together with the relevant key). Eor each of the 
distinct usages of the KDE, the input parameters Si are specified below. 



A.1 .2 FC value allocations 



The EC number space is used controlled by TS 33.220 [8], EC values allocated for this specification are in range of 
0x10 -OxlE. 
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A.2 KASME derivation function (Sio) 

When deriving a Kasme from CK, IK and SN id when producing authentication vectors, and when the UE computes 
Kasme during AKA, the following parameters shall be used to form the input S to the KDF. 

- FC = 0x10, 

- PO = SN id, 

- LO = length of SN id (i.e. 0x00 0x03), 

- PI = SQN e AK 

- LI = length of SQN © AK (i.e. 0x00 0x06) 

NOTE: The string S indexes start from 10 to align with the FC values and Annex subclause numbering. 

The exclusive or of the Sequence Number (SQN) and the Anonymity Key (AK) is sent to the UE as a part of the 
Authentication Token (AUTN), see TS 33.102. If AK is not used, AK shall be treated in accordance with TS 33.102, 
i.e. as 000... 0. 

The SN id consists of MCC and MNC, and shall be encoded as an octet string according to Figure A.2-1. 



MCC digit 2 


MCC digit 1 


MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 



octet 1 
octet 2 
octet 3 



Figure A.2-1 Encoding of SN id as an octet string 

The coding of the digits of MCC and MNC shall be done according to TS 24.301 [9]. 
The input key Key shall be equal to the concatenation CK II IK of CK and IK. 
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A.3 KeNB derivation function used at ECIVI-IDLE to 

ECM-CONNECTED transition, ECM-IDLE mode 
mobility, transition away from EIVIIVI- 
DEREGISTERED to EMM-REGISTERED/ECM- 
CONNECTED, key change on-the-fly and TAU and 
handover from UTRAN/GERAN to EUTRAN (Sn) 

When deriving a KeNB from Kasme and the uplink NAS COUNT in the UE and the MME the following parameters shall 
be used to form the input S to the KDF. During TAU and handover from UTRAN/GERAN to EUTRAN and when 
mapped context is used, the upUnk NAS COUNT is set to by the UE and the MME. 

- EC = 0x11, 

- PO = Uplink NAS COUNT, 

- LO = length of uplink NAS COUNT (i.e. 0x00 0x04) 
The input key shall be the 256-bit Kasme- 

A.4 NH derivation function (S12) 

When deriving a NH from Kasme the following parameters shall be used to form the input S to the KDF. 

- EC = 0x12 

- PO = SYNC-input 

- LO = length of SYNC-input (i.e. 0x00 0x20) 

The SYNC-input parameter shall be the newly derived KeNB for the initial NH derivation, and the previous NH for all 
subsequent derivations. This results in a NH chain, where the next NH is always fresh and derived from the previous 
NH. 

The input key shall be the 256-bit Kasme- 

A.5 KeNB* derivation function (S13) 

When deriving a KeNB* from current KgNB or from fresh NH and the target physical cell ID in the UE and eNB as 
specified in clause 7.2.8 for handover purposes the following parameters shall be used to form the input S to the KDE. 

- EC = 0x13 

- PO = PCI (target physical cell id) 

- LO = length of PCI (i.e. 0x00 0x02) 

PI = EARECN-DL (target physical cell downlink frequency) 

- LI length of EARECN-DL (i.e. 0x00 0x02) 

The input key shall be the 256-bit NH when the index in the handover increases, otherwise the current 256-bit Ksnb- 
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A.6 Void 



A.7 Algorithm key derivation functions (S15) 

When deriving keys for NAS integrity and NAS encryption algorithms from Kasme and algorithm types and algorithm 
IDs, and keys for RRC integrity and RRC/UP encryption algorithms from Kcnb, in the UE, MME and eNB the 
following parameters shall be used to form the string S. 

- FC = 0x15 

PO = algorithm type distinguisher 

LO = length of algorithm type distinguisher (i.e. 0x00 0x01) 

PI = algorithm identity 

LI = length of algorithm identity (i.e. 0x00 0x01) 

The algorithm type distinguisher shall be NAS-enc-alg for NAS encryption algorithms and NAS-int-alg for NAS 
integrity protection algorithms. The algorithm type distinguisher shall be RRC-enc-alg for RRC encryption algorithms, 
RRC-int-alg for RRC integrity protection algorithms and UP-enc-alg for UP encryption algorithms (see table A. 6-1). 
The values 0x06 to OxfO are reserved for future use, and the values Oxf 1 to Oxff are reserved for private use. 

Table A.7-1 : Algorithm type distinguishers 



Algorithm 
distinguisher 


Value 


NAS-enc-alg 


0x01 


NAS-int-alg 


0x02 


RRC-enc-alg 


0x03 


RRC-int-alg 


0x04 


UP-enc-alg 


0x05 



The algorithm identity (as specified in clause 5) shall be put in the four least significant bits of the octet. The two least 
significant bits of the four most significant bits are reserved for future use, and the two most significant bits of the most 
significant nibble are reserved for private use. The entire four most significant bits shall be set to all zeros. 

For NAS algorithm key derivations, the input key shall be the 256-bit K^sme^ and for UP and RRC algorithm key 
derivations, the input key shall be the 256-bit KeNB- 

For an algorithm key of length n bits, where n is less or equal to 256, the n least significant bits of the 256 bits of the 
KDF output shall be used as the algorithm key. 



A.8 Kasme to CK', IK' derivation (Sie) 

This input string is used when there is a need to derive CK' II IK' from Kasme during mapping of security contexts from 
E-UTRAN to GERAN/UTRAN. Kasme is a 256-bit entity, and so is the concatenation of CK and IK (which are 128 bits 
each). The following input parameters shall be used. 

- FC = 0x16 

- PO = NAS downlink COUNT value 

- LO = length of NAS downlink COUNT value (i.e. 0x00 0x04) 
The input key shall be Kasme- 
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A.9 NAS token derivation for inter-RAT mobility (S17) 

The NAS -token used to ensure that a RAU is originating from the correct UE during IDLE mode mobility from E- 
UTRAN to UTRAN and GERAN, shall use the following input parameters. 

- EC = 0x17 

- PO = Downlink NAS COUNT 

- LO = length of downlink NAS COUNT (i.e. 0x00 0x04) 
The input key shall be the 256-bit Kasme- 



A. 10 K"asme from CK, IK derivation during handover (Sis) 

This input string is used when there is a need to derive a K'asme from concatenation of CK and IK and a NONCEmme 
during mapping of security contexts between GERAN/UTRAN and E-UTRAN during handover to E-UTRAN. 

K'asme is a 256-bit value. The NONCEmme is a 32-bit value. The following input parameters shall be used. 

- EC = 0x18 

- PO = NONCEmme 

- LO = length of NONCEmme (i.e. 0x00 0x04) 

The input key shall be the concatenation of CK II IK. 

The generation of NONCEmme shall be sufficiently random such that both the probability of the MME generating equal 
values of NONCEmme and the probability of an attacker being able to predict future values of NONCEmme over the 
duration of practical eavesdropping attacks on a particular user are extremely low. 

NOTE: A well-seeded strong PRNG would meet this requirement. A true RNG is not required. 

A.1 1 K'asme from CK, IK derivation during idle mode mobility 

(Sl9) 

This input string is used when there is a need to derive a Kasme from CK II IK, NONCEue, and NONCEmme during 
mapping of security contexts from GERAN/UTRAN to E-UTRAN. Kasme is a 256-bit entity, and so is the 
concatenation of CK and IK (which are 128 bits each). The following input parameters shall be used, where NONCEs 
are 32 bits long. 

- EC = 0x19, 

- PO = NONCEuE 

- LO = length of the NONCEue (i.e. 0x00 0x04) 

- PI = NONCEmme 

- LI = length of the NONCEmme (i-e. 0x00 0x04) 

The input key shall be the concatenation of CK II IK. 

The generation of NONCEue shall be sufficiently random such that both the probability of the UE generating equal 
values of NONCEue and the probability of an attacker being able to predict future values of NONCEue over the 
duration of practical eavesdropping attacks on a particular user are extremely low. 

NOTE: A well-seeded strong PRNG would meet this requirement. A true RNG is not required. 
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The generation of NONCEmme shall be as defined in clause A. 10. 
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A.1 2 Kasme to CKsRvcc, IKsrvcc derivation (Sia) 

This input string is used when there is a need to derive CKsrvccH IKsrvcc used in CS domain from Kasme during 
mapping of security contexts between E-UTRAN and GERAN/UTRAN. Kasme is a 256-bit element, and so is the 
concatenation of CKsrvcc and IKsrvcc (which are 128 bits each). 

- EC = OxlA 

- PO = NAS downlink COUNT value 

- LO = length of NAS downlink COUNT value (i.e. 0x00 0x04) 
The input key shall be Kasme- 



£75/ 



3GPP TS 33.401 version 8.4.0 Release 8 



64 



ETSI TS 133 401 V8.4.0 (2009-07) 



Annex B (normative): 

Algorithms for ciphering and integrity protection 

B.O EEAO Null ciphering algorithm 

The EEAO algorithm shall be implemented such that it has the same effect as if it generates a KEYSTREAM of all 
zeroes (see subclause B.1.1). The length of the KEYSTREAM generated shall be equal to the LENGTH input 
parameter. The generated KEYSTREAM requires no other input parameters but the LENGTH. Apart from this, all 
processing performed in association with ciphering shall be exactly the same as with any of the ciphering algorithms 
specified in this annex. 

NOTE: that EEAO provides no security. 



B.1 1 28-bit ciphering algorithm 
B.1.1 Inputs and outputs 

The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-bit COUNT, a 5-bit bearer 
identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e. 
LENGTH. The DIRECTION bit shall be for uplink and 1 for downlink. 

Figure B. 1-1 illustrates the use of the ciphering algorithm EEA to encrypt plaintext by applying a keystream using a bit 
per bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same 
keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext. 
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Figure B.1-1 : Ciphering of data 

Based on the input parameters the algorithm generates the output keystream block KEYSTREAM which is used to 
encrypt the input plaintext block PLAINTEXT to produce the output ciphertext block CIPHERTEXT. 

The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it. 
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B.1.2 128-EEA1 

128-EEAl is based on SNOW 3G and is identical to UEA2 as specified in [14]. The used IV is constructed the same 
way as in subclause 3.4 of that TS. 



B.1.3 128-EEA2 

128-EEA2 is based on 128-bit AES [15] in CTR mode [16] 

The sequence of 128-bit counter blocks needed for CTR mode Ti, T2, 



, Ti, ... shall be constructed as follows: 



The most significant 64 bits of Ti consist of COUNT[0] ..COUNT[31] | BEARER[0] .. BEARER[4] | DIRECTION 
I 0^* (i.e. 26 zero bits). These are written from most significant on the left to least significant on the right, so for 
example COUNT[0] is the most significant bit of Ti. 

The least significant 64 bits of Tj are all 0. 

Subsequent counter blocks are then obtained by applying the standard integer incrementing function (according to 
Appendix Bl in [16]) mod 2^"^ to the least significant 64 bits of the previous counter block. 



B.2 1 28-Bit integrity algorithm 
B.2.1 Inputs and outputs 

The input parameters to the integrity algorithm are a 128-bit integrity key named KEY, a 32-bit COUNT, a 5-bit bearer 
identity called BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the message itself i.e 
MESSAGE. The DIRECTION bit shall be for uplink and 1 for downlink. The bit length of the MESSAGE is 
LENGTH. 

Figure B.2-1 illustrates the use of the integrity algorithm EIA to authenticate the integrity of messages. 
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Figure B.2-1 : Derivation of IVIAC-I/NAS-IVIAC (or XI\flAC-l/XNAS-l\flAC) 

Based on these input parameters the sender computes a 32-bit message authentication code (MAC-I/NAS-MAC) using 
the integrity algorithm EIA. The message authentication code is then appended to the message when sent. The receiver 
computes the expected message authentication code (XMAC-I/XNAS-MAC) on the message received in the same way 
as the sender computed its message authentication code on the message sent and verifies the data integrity of the 
message by comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC. 
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B.2.2 128-EIA1 

128-EIAl is based on SNOW 3G and is implemented in the same way as UIA2 as specified in [14]. The used IV is 
constructed the same way as in subclause 4.4 of that TS, with the only difference being that FRESH [0], ... FRESH [31] 
shall be replaced by BEARER[0] . . . BEARER[4] | 0^^ (i.e. 27 zero bits) 

B.2.3 128-EIA2 

128-EIA2 is based on 128-bit AES [15] in CMAC mode [17]. 

The bit length of MESSAGE is BLENGTH. 

The input to CMAC mode is a bit string M of length Mien (see [18, section 5.5]). M is constructed as follows: 

Mo .. M31 = COUNT[0] .. COUNT[31] 

M32 .. M36 = BEARER[0] .. BEARER[4] 

M37 = DIRECTION 

M38 .. M63 = 0^" (i.e. 26 zero bits) 

M64 .. Mblength+63 = MESSAGE[0] .. MESSAGE[BLENGTH-1] 

and so Mien = BLENGTH + 64. 

AES in CMAC mode is used with these inputs to produce a Message Authentication Code T (MACT) of length Tien = 
32. T is used directly as the 128-EIA2 output MACT[0] .. MACT[31], with MACT[0] being the most significant bit of 
T. 
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Annex C (informative): 
Algorithm test data 

C.1 128-EEA2 

This section includes eight test data sets; all are presented in hex, while the first is also presented in binary. Some 
intermediate computational values are included to assist implementers in tracing bugs. Some notation is taken from the 
specification of CTR mode [16]. 

Bit ordering should be largely self explanatory, but in particular: 

The 5-bit BEARER is written in hex in a 'right aligned' form, i.e. as a two-hex-digit value in the range 00 to IF 
inclusive, with BEARER [0] as the msb of the first digit. 

Similarly the single DIRECTION bit is written in hex in 'right aligned' form, i.e. the DIRECTION bit is the Isb 
of the hex digit. 

Where the length of plaintext and ciphertext is not a multiple of 32 bits, they are written in hex in a 'left aligned' 
form, i.e. the least significant few bits of the last word will be zero. 



C.1.1 Test Set 1 



Key = (hex) d3c5d592 327fbllc 4035c668 OafScSdl 

Key = (bin) 11010011 11000101 11010101 10010010 00110010 01111111 10110001 00011100 
01000000 00110101 11000110 01101000 00001010 11111000 11000110 11010001 

Count = (hex) 398a59b4 

Count = (bin) 00111001 10001010 01011001 10110100 

Bearer = (hex) 15 

Bearer = (bin) 10101 

Direction = (hex) 1 

Direction = (bin) 1 

Length = 253 bits 

Plaintext = (hex) 981ba682 4clbfbla b4854720 29b71d80 8ce33e2c c3c0b5fc If3de8a6 dcSSblfO 

Plaintext = (bin) 10011000 00011011 10100110 10000010 01001100 00011011 11111011 00011010 
10110100 10000101 01000111 00100000 00101001 10110111 00011101 10000000 
10001100 11100011 00111110 00101100 11000011 11000000 10110101 11111100 
00011111 00111101 11101000 10100110 11011100 01100110 10110001 11110 

Counter block Tl = (hex) 398a59b4 acOOOOOO 00000000 00000000 

Counter block Tl = (bin) 00111001 10001010 01011001 10110100 10101100 00000000 00000000 00000000 

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

Keystream block 1 = (hex) 71e57e24 710ea81e 6398b52b da5f3f94 

Keystream block 1 = (bin) 01110001 11100101 01111110 00100100 01110001 00001110 10101000 00011110 

01100011 10011000 10110101 00101011 11011010 01011111 00111111 10010100 

Counter block T2 = (hex) 398a59b4 acOOOOOO 00000000 00000001 
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Counter block T2 = (bin) 00111001 10001010 01011001 10110100 10101100 00000000 00000000 00000000 

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 

Keystream block 2 = (hex) 3eede9f6 11328620 231f3flb 328b3f88 

Keystream block 2 = (bin) 00111110 11101101 11101001 11110110 00010001 00110010 10000110 00100000 

00100011 00011111 00111111 00011011 00110010 10001011 00111111 10001000 

Ciphertext = (hex) e9fed8a6 3dl55304 d71df20b f3e82214 b20ed7da d2f233dc 3c22d7bd eeed8e78 

Ciphertext = (bin) 11101001 11111110 11011000 10100110 00111101 00010101 01010011 00000100 

11010111 00011101 11110010 00001011 11110011 11101000 00100010 00010100 

10110010 00001110 11010111 11011010 11010010 11110010 00110011 11011100 

00111100 00100010 11010111 10111101 11101110 11101101 10001110 01111 



C.1.2 Test Set 2 



Key = 2bd6459f 82c440e0 952c4910 4805ff48 

Count = c675a64b 

Bearer = Oc 

Direction = 1 

Length = 798 bits 

Plaintext = 7ec61272 743bflSl 4726446a 6c38cedl 66f6ca76 eb543004 4286346c efl30f92 
922b0345 Od3a9975 e5bd2eaO eb55ad8e Ibl99e3e C4316020 e9alb285 e7627953 
59b7bdfd 39bef4b2 484583d5 afe082ae e638bf5f d5a60619 3901a08f 4ab41aab 
9bl34880 



Counter block Tl 
Keystream block 1 
Counter block T2 
Keystream block 2 
Counter block T3 
Keystream block 3 
Counter block T4 
Keystream block 4 
Counter block T5 
Keystream block 5 
Counter block T6 
Keystream block 6 
Counter block T7 
Keystream block 7 



= c675a64b 64000000 00000000 00000000 

= 27a77221 27fdbabd e67d5d34 44bd9d78 

= c675a64b 64000000 00000000 00000001 

= 7695ef70 3d743aa3 d242fc6a 268aOb5d 

= c675a64b 64000000 00000000 00000002 

= b66ecfl5 b626681d 412b5dd3 a55db6d9 

= c675a64b 64000000 00000000 00000003 

= f83d506c 9dfl87ad a578c902 eel4296f 

= c675a64b 64000000 00000000 00000004 

= 50f44f36 635604e0 8ff25047 8c750516 

= c675a64b 64000000 00000000 00000005 

= 735839e3 7ebe8579 7be34641 08f730bc 

= c675a64b 64000000 00000000 00000006 

= 8b4flb53 87da3277 a56f567d 8066fce2 



Ciphertext = 59616053 53c64bdc al5bl95e 288553a9 10632506 d6200aa7 90c4c806 c99904cf 
2445CC50 bblcfl68 a4967373 4e081b57 e324ce52 59cOe78d 4cd97b87 0976503c 
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0943f2cb 5ae8f052 C7b7d392 239587b8 956086bc abl88360 42e2e6ce 42432al7 
105c53dO 

C.1.3 Test Set 3 

Key = 0a8bSbd8 d9b08b08 d64e32dl 817777fb 

Count = 544d49cd 

Bearer = 04 

Direction = 

Length = 310 bits 

Plaintext = fd40a41d 370alf65 74509568 7d47bald 36d2349e 23f64439 2c8ea9c4 9d40cl32 
71aff264 d0f24800 

Counter block Tl = 544d49cd 20000000 00000000 00000000 

Keystream block 1 = 8835a92a 83blbdcl aa8bal4b 2691367b 

Counter block T2 = 544d49cd 20000000 00000000 00000001 

Keystream block 2 = 737eee32 87777c9a 9c4ad826 3a44db65 

Counter block T3 = 544d49cd 20000000 00000000 00000002 

Keystream block 3 = 158c20f6 a275b8f5 Oe8ae073 997c58ed 

Ciphertext = 75750d37 b4bba2a4 dedb3423 5bd68c66 45acdaac a48138a3 bOc471e2 a7041a57 
6423d292 7287fOOO 



C.1.4 Test Set 4 



Key = aalf95ae a533bcb3 2eb63bf5 2d8f831a 

Count = 72d8c671 

Bearer = 10 

Direction = 1 

Length = 1022 bits 

Plaintext = fblb96c5 c8badfb2 e8e8edfd e78e57f2 ad81e741 03fc430a 534dcc37 afcec70e 
1517bb06 f27219da e49022dd c47a068d e4c9496a 951a6b09 edbdc864 c7adbd74 
0ac50c02 2f3082ba fd22d781 97c5d508 b977bcal 3f32e652 e74ba728 576077ce 
628c535e 87dc6077 ba07d290 68590c8c b5fl088e 082cfaOe c961302d 69cf3d44 

Counter block Tl = 72d8c671 84000000 00000000 00000000 

Keystream block 1 = 24afd669 7bcdeafb 0728abd5 49368fe7 

Counter block T2 = 72d8c671 84000000 00000000 00000001 

Keystream block 2 = cff4c44a df954e9e e34041a2 5d428c58 

Counter block T3 = 72d8c671 84000000 00000000 00000002 

Keystream block 3 = 2568dbf2 3827f27c 857b98af 68fa8925 

Counter block T4 = 72d8c671 84000000 00000000 00000003 
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Keystream block 4 
Counter block T5 
Keystream block 5 
Counter block T6 
Keystream block 6 
Counter block T7 
Keystream block 7 
Counter block T8 
Keystream block 8 



20576fl2 lbca2154 8ddl7c7c 19d93aff 
72d8c671 84000000 00000000 00000004 
90e7f4ed 0669897e 16751e7b 6001c02c 
72d8c671 84000000 00000000 00000005 
llf20436 a370d97d 68c5a2ba fee7e5cf 
72d8c671 84000000 00000000 00000006 
dcf3aa29 fdca4acf aaf961b4 d22dc84d 
72d8c671 84000000 00000000 00000007 
e31145b7 015ef36b f3a20e77 36e2b523 



Ciphertext = dfb440ac b3773549 efc04628 aeb8d815 6275230b dc690d94 b00d8d95 f28c4b56 

307f60f4 ca55eba6 61ebba72 ac808fa8 c49e2678 8ed04a5d 606cb418 de74878b 

9a22f8ef 29590bc4 eb57c9fa f7c41524 a885b897 9c423f2f 8f8e0592 a9879201 

be7ff977 7al62ab8 10feb324 ba74c4cl 56e04d39 09720965 3ac33e5a 5f2d8864 



C.1.5 Test Set 5 



Key = 9618ae46 891f8657 8eebe90e f7al202e 

Count = c675a64b 

Bearer = Oc 

Direction = 1 

Length = 1245 bits 

Plaintext = 8daal7bl ae050529 c6827f28 cOef6al2 42e93f8b 314fbl8a 77f790ae 049fedd6 
12267fec aefc4501 74d76d9f 9aa7755a 30cd90a9 a5874bf4 8eaf70ee a3a62a25 
0a8b6bd8 d9b08b08 d64e32dl 817777fb 544d49cd 49720e21 9dbf8bbe d33904el 
fd40a41d 370alf65 74509568 7d47bald 36d2349e 23f64439 2c8ea9c4 9d40cl32 
71aff264 dOf24841 d6465f09 96ff84e6 5fc517c5 3efc3363 c38492a8 



Counter block Tl 
Keystream block 1 
Counter block T2 
Keystream block 2 
Counter block T3 
Keystream block 3 
Counter block T4 
Keystream block 4 
Counter block T5 
Keystream block 5 
Counter block T6 
Keystream block 6 
Counter block T7 



c675a64b 64000000 00000000 00000000 
Ic369b82 78628C59 fb87dfff 0e6dc8bc 
c675a64b 64000000 00000000 00000001 
eea7d8e7 3e0211da 44a91a2a e3169673 
c675a64b 64000000 00000000 00000002 
cd094951 ffc2780d flafaa3f 665736ba 
c675a64b 64000000 00000000 00000003 
0a6e3336 If2a36el 30a83f44 fe3603d2 
c675a64b 64000000 00000000 00000004 
153f3c6e 9e33cclc 66afbdc0 febd679c 
c675a64b 64000000 00000000 00000005 
2d0840al C52d3c4a 356982eO 61a53ad7 
c675a64b 64000000 00000000 00000006 
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Keystream block 7 = 3264f90b 15aOelf7 6b25f3ac 8891feef 

Counter block T8 = c675a64b 64000000 00000000 00000007 

Keystream block 8 = c72e3a58 a72bf62a 65fadfe6 7f49e86f 

Counter block T9 = c675a64b 64000000 00000000 00000008 

Keystream block 9 = 5650cdfl b2cl3995 4d522303 627993f9 

Counter block TIO = c675a64b 64000000 00000000 00000009 

Keystream block 10 = 7d081374 f517153b elbafb97 3f9dd804 

Ciphertext = 919c8c33 d6678970 3d05a0d7 ce82a2ae ac4ee76c 0f4da050 335e8a84 e7897ba5 

df2f36bd 513e3d0c 8578c7a0 fcf043eO 3aa3a39f baad7dl5 be074faa 5d9029f7 

Ifb457b6 47834714 b0el8fll 7fcal067 7945096c 8c5f326b a8d6095e b29c3e36 

cf245dl6 22aafe92 If7566c4 f5d644f2 flfc0ec6 84ddb213 49747622 e209295d 

27ff3f95 623371d4 9bl47cOa f486171f 22cd04bl cbeb2658 223e6938 



C.1.6 Test Set 6 



Key 

Count 

Bearer 



54f4e2eO 4c83786e ec8fb5ab e8e36566 

aca4f50f 

Ob 



Direction = 

Length = 3861 bits 

Plaintext = 40981ba6 824clbfb 4286b299 783daf44 2c099f7a bOf58d5c 8e46bl04 f08f01b4 
lab48547 2029b71d 36bdla3d 90dc3a41 b46d5167 2ac4c966 3a2be063 da4bc8d2 
808ce33e 2cccbfc6 34elb259 060876aO fbb5a437 ebcc8d31 Cl9e4454 318745e3 
fal6bbll adae2488 79fe52db 2543e53c f445d3d8 28ceObf5 c560593d 97278a59 
762ddOc2 c9cd68d4 496a7925 08614014 bl3b6aa5 1128cl8c d6a90b87 978c2ffl 
cabe7d9f 898a411b fdb84f68 f6727bl4 99cdd30d f0443ab4 a6665333 ObcballO 
5e4cec03 4c73e605 b4310eaa adcfdSbO ca27ffd8 9dl44df4 79275942 7c9cclf8 
cd8c8720 2364b8a6 87954cbO 5a8d4e2d 99e73dbl 60debl80 ad0841e9 6741a5d5 
9fe4189f 15420026 fe4cdl21 04932fb3 8f735340 438aaf7e ca6fd5cf d3al95ce 
5abe6527 2af607ad albe65a6 b4c9c069 3234092c 4d018fl7 56c6db9d c8a6d80b 
88813861 6b681262 f954dOe7 71174878 0d92291d 86299972 db741cfa 4f37b8b5 
6cdbl8a7 ca8218e8 6e4b4b71 6a4d0437 lfbec262 fc5adOb3 819bl87b 97e55bla 
4d7cl9ee 24c8b4d7 723cfedf 045b8aca e4869517 d80e5061 5d9035d5 d9c5a40a 
f602280b 542597bO cbl8619e eb359257 59dl95el 00e8e4aa 0c38a3c2 abe0f3d8 
ff04f3c3 3C295069 c23694b5 bbeacdd5 42e28e8a 94edb911 9f412d05 4belfa72 
00b09000 

Counter block Tl = aca4f50f 58000000 00000000 00000000 
Keystream block 1 = Ic2f37c8 5ecb94ee 2467bOca d7fecb8d 
Counter block T2 = aca4f50f 58000000 00000000 00000001 
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Keystream block 2 
Counter block T3 
Keystream block 3 
Counter block T4 
Keystream block 4 
Counter block T5 
Keystream block 5 
Counter block T6 
Keystream block 6 
Counter block T7 
Keystream block 7 
Counter block T8 
Keystream block 8 
Counter block T9 



d65d92eb fd4ccle2 6c336195 8c29aeb9 
aca4f50f 58000000 00000000 00000002 
6dl831a8 Ib97ad6f Id93ef80 8d97b46b 
aca4f50f 58000000 00000000 00000003 
116flfa6 124ee978 41e59943 748ddd5b 
aca4f50f 58000000 00000000 00000004 
dffad96b 48107b02 b6435c44 8df6bae4 
aca4f50f 58000000 00000000 00000005 
63590C08 50b9749a 929049fb 8f596a46 
aca4f50f 58000000 00000000 00000006 
734d3988 b6cc534d 501ea089 b83c9c5c 
aca4f50f 58000000 00000000 00000007 
9facb4de 01a3e60f 58144b8b 81b206ec 
aca4f50f 58000000 00000000 00000008 
Keystream block 9 = 15eba802 ele8abd9 43840eel c9279262 
Counter block TIO = aca4f50f 58000000 00000000 00000009 
Keystream block 10 = e52928bf 91a5d242 leb062cb e22178df 
Counter block Til = aca4f50f 58000000 00000000 0000000a 
Keystream block 11 = 5129400b 020be828 8183657f ef5c59d6 
Counter block T12 = aca4f50f 58000000 00000000 0000000b 
Keystream block 12 = 9f52addc e66ecef8 78ce4453 3dae4917 
Counter block T13 = aca4f50f 58000000 00000000 0000000c 
Keystream block 13 = 900c24e3 91ee8591 685f3fbf 922e40ec 
Counter block T14 = aca4f50f 58000000 00000000 OOOOOOOd 
Keystream block 14 = 8d884ac7 bb03a3f8 271cd7b3 dle9b515 
Counter block T15 = aca4f50f 58000000 00000000 OOOOOOOe 
Keystream block 15 = f9b25b07 60a82c6f 1774bd4d 7ccfldec 
Counter block T16 = aca4f50f 58000000 00000000 OOOOOOOf 
Keystream block 16 = el399a88 a0604f6b 6097da9f b3ddb5cO 
Counter block T17 = aca4f50f 58000000 00000000 00000010 
Keystream block 17 = 561ad7cf f0798b74 fa971clf e91517e6 
Counter block T18 = aca4f50f 58000000 00000000 00000011 
Keystream block 18 = 55cf8f89 08bb4c66 c87abd4a 8f2aOb9c 
Counter block T19 = aca4f50f 58000000 00000000 00000012 
Keystream block 19 = f33ff05d 3bde2054 d904f3a9 a08e5172 
Counter block T20 = aca4f50f 58000000 00000000 00000013 
Keystream block 20 = 034f5c3d b6cdf0a6 6c078846 bc83c91c 
Counter block T21 = aca4f50f 58000000 00000000 00000014 
Keystream block 21 = 6c0726d8 8353ed9d 3dbfa7b2 2687709d 
Counter block T22 = aca4f50f 58000000 00000000 00000015 
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Keystream block 22 = 74b698ea 0dl783ab d0df36fd c82cca6e 
Counter block T23 = aca4f50f 58000000 00000000 00000016 
Keystream block 23 = 32348e64 fe86518e b5477cbb 97578dd2 
Counter block T24 = aca4f50f 58000000 00000000 00000017 
Keystream block 24 = 7bd4f7e2 173eb542 a047flbO If3d008c 
Counter block T25 = aca4f50f 58000000 00000000 00000018 
Keystream block 25 = 825fd522 f0e0b3b0 ccd4106d 39ddd88c 
Counter block T26 = aca4f50f 58000000 00000000 00000019 
Keystream block 26 = f930dc26 db0e6bce d465d457 b82fe7c2 
Counter block T27 = aca4f50f 58000000 00000000 0000001a 
Keystream block 27 = bc90c3f4 abcl072d Of74300c 13106527 
Counter block T28 = aca4f50f 58000000 00000000 0000001b 
Keystream block 28 = 39da03e3 c5bf5152 b809045f ee778e01 
Counter block T29 = aca4f50f 58000000 00000000 0000001c 
Keystream block 29 = 3blf75fe 95c81280 c2165b65 cf3c5fae 
Counter block T30 = aca4f50f 58000000 00000000 OOOOOOld 
Keystream block 30 = 385138f8 C9f7d62e 07f8e4df e379d08d 
Counter block T31 = aca4f50f 58000000 00000000 OOOOOOle 
Keystream block 31 = 06c8b899 06c71bb9 2e834ee7 e81cdl09 

Ciphertext = 5cb72c6e dc878fl5 66el0253 afc364c9 fa540d91 4db94cbe e275d091 7ca6afOd 
77acb4ef 3bbela72 2b2ef5bd Id4b8e2a a5024ecl 388a201e 7bce7920 aec61589 
5f763a55 64dcc4c4 82a2eeld 8bfecc44 98eca83f bb75f9ab 530eOdaf bede2fa5 
895b8299 Ib6277c5 29eOf252 9d7f7960 6be96706 296dedfa 9d7412b6 16958cb5 
63c678cO 2825c30d Oaee77c4 Cl46d276 5412421a 808dl3ce c819694c 75ad572e 
9b973d94 8b81a933 7c3b2al7 192e22c2 069f7edl 162af44c dea81760 3665e807 
ce40c8eO dd9d6394 dc6e3115 3fel955c 47afb51f 2617eeOc 5e3b8efl ad7574ed 
343edc27 43cc94c9 90elflfd 264253cl 78dea739 cObefeeb cd9f9b76 d49cl015 
c9fecf50 e53b8b52 04dbcd3e ed863855 dabcdcc9 4b31e318 02156885 5c8b9e52 
a981957a 112827f9 78ba960f 1447911b 317b5511 fbcc7fbl 3acl53db 74251117 
e4861eb9 e83bffff c4eb7755 579038e5 7924blf7 8b3elad9 Obab2a07 871b72db 
5eef96c3 34044966 dbOc37ca fdla89e5 646a3580 eb6465fl 21dce9cb 88d85b96 
cf23cccc d4280767 bee8eeb2 3d865246 ldb64931 03003baf 89f5el82 61ea43c8 
4a92ebff ffe4909d c46c5192 f825f770 600b9602 C557b5f8 b431a79d 45977dd9 
c41b863d a9el42e9 0020cfdO 74d6927b 7ab3b672 5dla6f3f 98b9c9da a8982aff 
06782800 
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C.2 128-EIA2 



This section includes six test data sets; all are presented in hex, while the first is also presented in binary. Many 
intermediate computational values are included to assist implementers in tracing bugs. Some notation is taken from the 
specification of CMAC mode [17]. 

Bit ordering should be largely self explanatory, but in particular: 

The 5-bit BEARER is written in hex in a 'right aligned' form, i.e. as a two-hex-digit value in the range 00 to IF 
inclusive, with BEARER [0] as the msb of the first digit. 

Similarly the single DIRECTION bit is written in hex in 'right aligned' form, i.e. the DIRECTION bit is the Isb 
of the hex digit. 

Where the length of the message, or of a message sub-block, is not a multiple of 32 bits, it is written in hex in a 
'left aligned' form, i.e. the least significant few bits of the last word will be zero. 

C.2.1 Test Set 1 

Count-I = (hex) 38a6f056 

Count-I = (bin) 00111000 10100110 11110000 01010110 

Bearer = (hex) 18 

Bearer = (bin) 11000 

Direction = (hex) 

Direction = (bin) 

IK = (hex) 2bd6459f 82c5b300 952c4910 4881ff48 

IK = (bin) 00101011 11010110 01000101 10011111 10000010 11000101 10110011 00000000 
10010101 00101100 01001001 00010000 01001000 10000001 11111111 01001000 

Length = 58 bits 

Message = (hex) 33323462 63393840 

Message = (bin) 00110011 00110010 00110100 01100010 01100011 00111001 00111000 01 

CMAC{K, M) : 

K = (hex) 2bd6459f 82c5b300 952c4910 4881ff48 

K = (bin) 00101011 11010110 01000101 10011111 10000010 11000101 10110011 00000000 

10010101 00101100 01001001 00010000 01001000 10000001 11111111 01001000 
Mien = 122 

M = (hex) 38a6f056 cOOOOOOO 33323462 63393840 

M = (bin) 00111000 10100110 11110000 01010110 11000000 00000000 00000000 00000000 

00110011 00110010 00110100 01100010 01100011 00111001 00111000 01 

Subkey Generation: 

L = (hex) 6e426138 Badfclfc b7c85f0c 469fb20c 

L = (bin) 01101110 01000010 01100001 00111000 01011010 11011111 11000001 11111100 

10110111 11001000 01011111 00001100 01000110 10011111 10110010 00001100 

Kl = (hex) dc84c270 b5bf83f9 6f90bel8 8d3f6418 
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Kl = (bin) 11011100 10000100 11000010 01110000 10110101 10111111 10000011 11111001 

01101111 10010000 10111110 00011000 10001101 00111111 01100100 00011000 

K2 = (hex) b90984el 6b7f07f2 df217c31 Ia7ec8b7 

K2 = (bin) 10111001 00001001 10000100 11100001 01101011 01111111 00000111 11110010 

11011111 00100001 01111100 00110001 00011010 01111110 11001000 10110111 

MAC Generation: 

n =1 

Mn* = (hex) 38a6f056 cOOOOOOO 33323462 S3393840 

Mn* = (bin) 00111000 10100110 11110000 01010110 11000000 00000000 00000000 00000000 

00110011 00110010 00110100 01100010 01100011 00111001 00111000 01 

Mn = (hex) 81af74b7 ab7f07f2 ecl34853 7947fOd7 

Mn = (bin) 10000001 10101111 01110100 10110111 10101011 01111111 00000111 11110010 

11101100 00010011 01001000 01010011 01111001 01000111 11110000 11010111 

CO = (hex) 00000000 00000000 00000000 00000000 

CO = (bin) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

Ml = (hex) 81af74b7 ab7f07f2 ecl34853 7947fOd7 

Ml = (bin) 10000001 10101111 01110100 10110111 10101011 01111111 00000111 11110010 

11101100 00010011 01001000 01010011 01111001 01000111 11110000 11010111 

CI = (hex) 118c6eb8 b775144b 0b831110 54c96eb6 

CI = (bin) 00010001 10001100 01101110 10111000 10110111 01110101 00010100 01001011 

00001011 10000011 00010001 00010000 01010100 11001001 01101110 10110110 

MACT = (hex) 118c6eb8 

MACT = (bin) 00010001 10001100 01101110 10111000 

C.2.2 Test Set 2 

Count-I = 398a59b4 

Bearer = la 

Direction = 1 

IK = d3c5d592 327fbllc 4035c668 0af8c6dl 

Length = 64 bits 

Message = 484583d5 afe082ae 

CMAC{K, M) : 

K = d3c5d592 327fbllc 4035c668 0af8c6dl 

Mien = 128 

M = 398a59b4 d4000000 484583d5 afe082ae 
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Subkey Generation: 

L = 9b71f299 132915d3 S05211b5 e5df8632 

Kl = 36e3e532 26522ba6 cOa4236b cbbf0ce3 
K2 = 6dc7ca64 4ca4574d 814846d7 977el9c6 

MAC Generation: 

n =1 

Mn* = 398a59b4 d4000000 484583d5 afe082ae 

Mn = 0f69bc86 f2522ba6 88ela0be 645f8e4d 

CO = 00000000 00000000 00000000 00000000 

Ml = 0f69bc86 f2522ba6 88ela0be 645f8e4d 

CI = b93787e6 493ffll3 ad73d3eO Ie826d73 

MACT = b93787e6 

C.2.3 Test Set 3 

Count-I = 36af6144 

Bearer = 18 

Direction = 1 

IK = 7e5e9443 lelld738 28d739cc 6ced4573 

Length = 254 bits 

Message = b3d3c917 Oa4el632 f60f8610 13d22d84 b726b6a2 78d802dl eeafl321 ba5929dc 

CMAC{K, M) : 

K = 7e5e9443 lelld738 28d739cc 6ced4573 

Mien = 318 

M = 36af6144 C4000000 b3d3c917 Oa4el632 f60f8610 13d22d84 b726b6a2 78d802dl 

eeafl321 ba5929dc 

Subkey Generation: 

L = d78b4628 35781e79 d2255f8d 309a60ef 

Kl = afl68c50 6af03cf3 a44abfla 6134cl59 
K2 = 5e2dl8aO d5e079e7 48957e34 C2698235 

MAC Generation: 

n =3 

Mn* = eeafl321 ba5929dc 

Mn = b0820b81 6fb95039 48957e34 c2698235 
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CO 
Ml 
CI 
M2 
C2 
MS 
C3 



00000000 00000000 00000000 00000000 
36af6144 C4000000 b3d3c917 Oa4el632 
3bb0eld8 2cb96273 64a7cfd3 a52eedl5 
f60f8610 13d22d84 b726b6a2 78d802dl 
e3a6446d fae7fl0f e3e3320d a8e49955 
b0820b81 6fb95039 48957e34 C2698235 
IfeObOld e05aa666 3bda32c6 1771e70b 



MACT 



IfSObOld 



C.2.4 Test Set 4 



Count-I = c7590ea9 
Bearer = 17 
Direction = 

IK = d3419be8 21087acd 02123a92 48033359 
Length = 511 bits 

Message = bbb05703 880949Sb cff8SdSf bc8ce5bl 35aOSblS S054f2d5 S5be8ace 75dc851e 
0bcdd8f0 7141C495 872fb5d8 c0c66a8b 6da55666 3e4e4612 05d84580 bee5bc7e 

CMAC{K, M) : 

K = d3419be8 21087acd 02123a92 48033359 

Mien = 575 

M = c7590ea9 b8000000 bbb05703 880949Sb cff8SdSf bc8ce5bl 35aOSblS S054f2d5 

65be8ace 75dc851e 0bcdd8f0 7141c495 872fb5d8 c0c66a8b 6da55666 3e4e4612 

05d84580 bee5bc7e 



Subkey Generation: 



L 

Kl 

K2 



054dd008 2d9ecd21 a3f32b0a a7369be4 
0a9ba010 5b3d9a43 47e65615 4e6d37c8 
15374020 b67b3486 8fccac2a 9cda6f90 



MAC Generation: 



n 

Mn* 
Mn 

CO 
Ml 
CI 
M2 



05d84580 bee5bc7e 

10ef05a0 089e88f9 8fccac2a 9cda6f90 
00000000 00000000 00000000 00000000 
c7590ea9 b8000000 bbb05703 8809496b 
cb36ed77 e49bd772 ac410f25 eea31084 
cff86d6f bc8ce5bl 35a06bl6 6054f2d5 
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C2 
MS 
C3 

iyi4 

C4 
MS 
C5 



e44baf91 d48ba92c 542f3bl4 a8a496d9 
65be8ace 75dc851e 0bcdd8f0 7141c495 
C3542869 eed00692 e3b4efla 6b324aaf 
872fb5d8 c0c66a8b 6da55666 3e4e4612 
5054d998 92675b0f 989d3b0f 3c043c4e 
lOefOSaO 089e88f9 8fccac2a 9cda6f90 
6846a2fO aOb6be7a 4fb26al5 7e914c53 



MACT 



6846a2f0 



C.2.5 Test Set 5 



Count-I = 36af6144 

Bearer = Of 

Direction = 1 

IK = 83fd23a2 44a74cf3 58da3019 fl722S35 

Length = 768 bits 

Message = 35c68716 S33cSSfb 750c2SS8 S5d53cll ea05ble9 fa49c839 8d48elef a5909d39 
47902837 f5ae96d5 a05bc8d6 lca8dbef Ibl3a4b4 abfe4fbl 006045b6 74bb5472 
9304C382 be53a5af 05556176 f6eaa2ef Id05e4b0 83181ee6 74cda5a4 85f74d7a 

CMACCK, M) : 

K = 83fd23a2 44a74cf3 58da3019 fl722635 

Mien = 832 

M = 36af6144 7cOOOOOO 35c68716 633c66fb 750c2668 65d53cll ea05ble9 fa49c839 

8d48elef a5909d39 47902837 f5ae96d5 a05bc8d6 lca8dbef Ibl3a4b4 abfe4fbl 
006045b6 74bb5472 9304c382 be53a5af 05556176 f6eaa2ef Id05e4b0 83181ee6 
74cda5a4 85f74d7a 

Subkey Generation: 

L = 9df61c57 3c86acac 704db9d5 bOdea444 

Kl = 3bec38ae 790d5958 e09b73ab 61bd480f 
K2 = 77d8715c f21ab2bl Cl36e756 c37a901e 

MAC Generation: 

n =7 

Mn* = 74cda5a4 85f74d7a 

Mn = 0315d4f8 77edffcb 4136e756 c37a901e 

CO = 00000000 00000000 00000000 00000000 

Ml = 36af6144 7cOOOOOO 35c68716 633c66fb 
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ci 

M2 
C2 
MS 
C3 
iyi4 
C4 
MS 
C5 
MS 
C6 
M7 
C7 



57c5a916 el9d7747 c2a69283 5eed0015 
750C2668 65d53cll ea05ble9 fa49c839 
7937651c b2c34e23 646b4396 f77bcaOd 
8d48elef a5909d39 47902837 f5ae96d5 
dfa3c570 d7b4dd08 2533b643 f82f646c 
a05bc8d6 lca8dbef Ibl3a4b4 abfe4fbl 
7a8e64cO eb34df52 64236368 Of019ddd 
006045b6 74bb5472 9304c382 be53a5af 
3f5f08a2 5a6a8ba8 9a5dd816 626a26ef 
05556176 f6eaa2ef Id05e4b0 83181ee6 
9fe7991a 50c5f542 eObfOdaO 9decl456 
0315d4f8 77edffcb 4136e756 c37a901e 
e657el82 5298f2fa ee2caleO 7373bc7e 



MACT 



e657el82 



C.2.6 Test Set 6 



Count-I = 36af6144 
Bearer = 18 
Direction = 

IK = 6832a65c ff447362 lebdd4ba 26a921fe 
Length = 383 bits 

Message = d3c53839 62682071 77656676 20323837 63624098 lba6824c lbfblab4 85472029 
b71d808c e33e2cc3 cOb5fclf 3de8a6dc 

CMACCK, M) : 

K = 6832a65c ff447362 lebdd4ba 26a921fe 

Mien = 447 

M = 36af6144 cOOOOOOO d3c53839 62682071 77656676 20323837 63624098 lba6824c 

lbfblab4 85472029 b71d808c e33e2cc3 cOb5fclf 3de8a6dc 

Subkey Generation: 

L = e50123c3 87el3fd6 8d8bf0d0 a4581685 

Kl = ca024787 Ofc27fad lbl7elal 48b02d8d 
K2 = 94048fOe If84ff5a 362fc342 91605b9d 

MAC Generation: 

n =4 

Mn* = cOb5fclf 3de8a6dc 
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Mn 

CO 
Ml 
CI 
M2 
C2 
MS 
C3 
iyi4 
C4 



54bl7311 226C5987 362fc342 91605b9d 
00000000 00000000 00000000 00000000 
3Saf6144 cOOOOOOO d3c53839 62682071 
263dd98f beccb69a 428e92d4 21fbed9e 
77656676 20323837 63624098 lba6824c 
1838cb78 cb2d32dc ec486c79 d9007al9 
lbfblab4 85472029 b71d808c e33e2cc3 
5ebfl009 f663be7b 68373072 4c20271f 
54bl7311 226C5987 362fc342 91605b9d 
f0668cle 4197300b 1243f834 25d06c25 



MACT 



f0668cle 



C.2.7 Test Set 7 



Count -I 
Bearer 



7827fab2 
05 



Direction = 1 

IK = 5d0a80d8 134ael96 77824b67 Ie838af4 

Length = 2558 bits 

Message = 70dedf2d c42c5cbd 3a96f8a0 bll418b3 608d5733 604a2cd3 6aabc70c e3193bb5 

153be2d3 c06dfdb2 dl6e9c35 7158be6a 41d6b861 e491db3f bfeb518e fcf048d7 

d5895373 0ff30c9e c470ffcd 663dc342 01c36add c0111c35 b38afee7 cfdb582e 

3731f8b4 baa8dla8 9c06e811 99a97162 27be344e fcb436dd dOf096cO 64c3b5e2 

c399993f c77394f9 e09720a8 11850ef2 3b2ee05d 9e617360 9d86elcO Cl8ea51a 

012a00bb 413b9cb8 188a703c d6bae31c c67b34bl b00019e6 a2b2a690 f02671fe 

7c9ef8de c0094e53 3763478d 58d2c5f5 b827a014 8c5948a9 6931acf8 4f465a64 

e62ce740 07e991e3 7ea823fa Ofb21923 b79905b7 33b631e6 c7d6860a 3831ac35 

Ia9c730c 52ff72d9 d308eedb ab21fdel 43aOeal7 e23edclf 74cbb363 8a2033aa 

al5464ea a733385d bbeb6fd7 3509b857 e6a419dc ald8907a f977fbac 4dfa35ec 

CMAC{K, M) : 

K = 5d0a80d8 134ael96 77824b67 Ie838af4 

Mien = 2622 

M = 7827fab2 2cOOOOOO 70dedf2d c42c5cbd 3a96f8a0 bll418b3 608d5733 604a2cd3 

6aabc70c e3193bb5 153be2d3 c06dfdb2 dl6e9c35 7158be6a 41d6b861 e491db3f 

bfeb518e fcf048d7 d5895373 Off30c9e c470ffcd 663dc342 01c36add c0111c35 

b38afee7 cfdb582e 3731f8b4 baa8dla8 9c06e811 99a97162 27be344e fcb436dd 

dOf096cO 64c3b5e2 c399993f c77394f9 e09720a8 11850ef2 3b2ee05d 9e617360 

9d86elc0 Cl8ea51a 012a00bb 413b9cb8 188a703c d6bae31c c67b34bl b00019e6 

a2b2a690 f02671fe 7c9ef8de c0094e53 3763478d 58d2c5f5 b827a014 8c5948a9 
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6931acf8 4f465a64 e62ce740 07e991e3 7ea823fa 0fb21923 b79905b7 33b631e6 

c7d6860a 3831ac35 Ia9c730c 52ff72d9 d308eedb ab21fdel 43aOeal7 e23edclf 

74cbb363 8a2033aa al5464ea a733385d bbeb6fd7 3509b857 e6a419dc ald8907a 

f977fbac 4dfa35ec 

Subkey Generation: 

L = 9832e229 fbb93970 bcf7b282 3ee4fe5d 

Kl = 3065C453 f77272el 79ef6504 7dc9fc3d 

K2 = S0cb88a7 eee4e5c2 f3deca08 fb93f87a 

MAC Generation: 

n =21 

Mn* = f977fbac 4dfa35ec 

Mn = 99bc730b a31ed02c f3deca08 fb93f87a 

CO = 00000000 00000000 00000000 00000000 

Ml = 7827fab2 2c000000 70dedf2d c42c5cbd 

CI = 6c9b07cO 35b7a016 3aadl405 If57f3e0 

M2 = 3a96f8a0 bll418b3 608d5733 604a2cd3 

C2 = ec9c6b75 ld027216 3412fad4 fOlcebba 

MS = Saabc70c e3193bb5 153be2d3 c06dfdb2 

C3 = 3c83db67 ff87c86b 57ae4742 42c9816b 

iyi4 = dl6e9c35 7158be6a 41d6b861 e491db3f 

C4 = e6e894ee 7el48494 44afcb75 9752e555 

MS = bfeb518e fcf048d7 d5895373 Off30c9e 

C5 = cbf27dfl Ofd514fO 489dd303 d2dbee51 

MS = c470ffcd 663dc342 01c36add c0111c35 

C6 = 6989143a 39de09ab 2680fe6c 41fOa7cl 

iyi7 = b38afee7 cfdb582e 3731f8b4 baa8dla8 

C7 = fe4049fa 655ee010 49299c58 c91024ff 

MS = 9c06e811 99a97162 27be344e fcb436dd 

C8 = Ie9dab32 48d5ee47 C7e3a420 6fl8bl7b 

iyi9 = d0f096c0 64c3b5e2 c399993f c77394f9 

C9 = 9da578a5 00a0c7fl e825a4ca 71557055 

MID = e09720a8 11850ef2 3b2ee05d 9e617360 

CIO = 4141C882 a23da353 2bll642a 85fea2bf 

Mil = 9d86elcO Cl8ea51a 012a00bb 413b9cb8 

Cll = 18467572 Obdfcb5b 6bb71899 a6cafcc7 

M12 = 188a703c d6bae31c c67b34bl b00019e6 

C12 = 156a70e5 af77f9a4 74d08303 e8c0412a 
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MIS 
C13 

iyii4 

C14 
MIS 
C15 
M16 
C16 
Ml? 
C17 
M18 
C18 
iyil9 
C19 

iyi2 

C2 
M21 
C21 



a2b2a690 f02671fe 7c9ef8de c0094e53 
dba504al 26fa047f 8b8c295f 73e90a5c 
3763478d 58d2c5f5 b827a014 8c5948a9 
abla2703 3472acc8 e36c221b b7a0e530 
6931acf8 4f465a64 e62ce740 07e991e3 
04ceffcd 67618885 43c7e837 0f3bce6d 
7ea823fa 0fb21923 b79905b7 33b631e6 
215ec3bf 5f3a303e 53db5269 e6c99fc2 
c7d6860a 3831ac35 Ia9c730c 52ff72d9 
8622e51b 45a660f3 d98fcf74 e5cc36b3 
d308eedb ab21fdel 43aOeal7 e23edclf 
6e998fa6 196d5a4c lded2973 c09cOf8c 
74cbb363 8a2033aa al5464ea a733385d 
1710bc91 22e54289 244a87ce 23438f41 
bbeb6fd7 3509b857 e6a419dc ald8907a 
3el8b029 a8efl8da b9968614 96552fd7 
99bc730b a31ed02c f3deca08 fb93f87a 
f4cc8fa3 59e6e2e7 6e09c45d 6ea5eOde 



MACT 



f4cc8fa3 



C.2.8 Test Set 8 



Count-I = 296f393c 

Bearer = Ob 

Direction = 1 

IK = b3120ffd b2cf6af4 e73eaf2e f4ebecS9 

Length = 16448 bits 

Message = 00000000 00000000 01010101 01010101 e0958045 f3aObba4 e39S834S fOa3b8a7 
c02a018a e6407652 26b987c9 13e6cbf0 83570016 cf83efbc 61c08251 3e21561a 
427c009d 28c298ef ace78ed6 d56c2d45 05ad032e 9c04dc60 e73a8169 6da665c6 
c48603a5 7b45ab33 221585e6 8ee31691 87fb0239 528632dd 656c807e a3248b7b 
46d002b2 b5c7458e b85b9ce9 5879e034 0859055e 3b0abbc3 eace8719 caa80265 
c97205d5 dc4bcc90 2fel8396 29ed7132 8aOf0449 f588557e 6898860e 042aecd8 
4b2404c2 12c9222d a5bf8a89 ef679787 Ocf50771 a60f66a2 ee628536 57addf04 
cdde07fa 414ellfl 2b4d81b9 b4e8ac53 8ea30666 688d881f 6c348421 992f31b9 
4f8806ed 8fccff4c 9123b896 42527ad6 13bl09bf 75167485 fl268bf8 84b4cd23 
d29a0934 925703d6 34098f77 67flbe74 91e708a8 bb949a38 73708aef 4a36239e 
50CC0823 5cd5ed6b be578668 al7b58cl 171dOb90 e813a9e4 f58a89d7 19bll042 
d6360blb Of52deb7 30a58d58 faf46315 954bOa87 26914759 77dc88cO d733feff 
54600aOc cld0300a aaeb9457 2c6e95bO Iae90de0 4fldce47 f87e8fa7 bebf77el 
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dbc20d6b a85cb914 3d518b28 5dfa04b6 98bf0cf7 819f20fa 7a288eb0 703d995c 

59940c7c 66de57a9 b70f8237 9b70e203 le450fcf d2181326 fcd28d88 23baaa80 

df6eOf44 35596475 39fd8907 cOffd9d7 9cl30ed8 Ic9afd9b 7e848c9f ed38443d 

5d380e53 fbdb8ac8 c3d3f068 76054fl2 2461107d e92fea09 c6f6923a 188d53af 

e54al0f6 Oe6e9d5a 03d996b5 fbc820f8 a637116a 27ad04b4 44a0932d d60fbdl2 

671cllel C0ec73e7 89879faa 3d42c64d 20cdl252 742a3768 c25a9015 85888ece 

ele612d9 936b403b 0775949a 66cdfd99 a29bl345 baa8d9d5 400c9102 4bOa6073 

63b013ce 5de9ae86 9d3b8d95 b0570b3c 2d391422 d32450cb cfae9665 2286e96d 

ecl214a9 34652798 Oa8192ea Clc39a3a af6fl535 Ida6be76 4df89772 ec0407dO 

6e4415be fae7c925 80df9bf5 07497c8f 2995160d 4e218daa cb02944a bf83340c 

e8bel686 a960faf9 Oe2d90c5 5cc6475b abc3171a 80a36317 4954955d 7101dabl 

6ae81791 67e21444 b443a9ea aa7c91de 36dll8c3 9d389f8d d4469a84 6c9a262b 

f7fal848 7a79e8de 11699eOb 8fdf557c b48719d4 53ba7130 56109b93 a218c896 

75acl95f b4fb0663 9b379714 4955b3c9 327dlaec 003d42ec dOea98ab fl9ffb4a 

f3561a67 e77c35bf 15c59c24 12da881d b02blbfb cebfac51 52bc99bc 3fldl5f7 

71001b70 29fedb02 8f8b852b c4407eb8 3f891c9c a733254f ddle9edb 56919ce9 

fea21cl7 4072521c 18319a54 b5d4efbe bddfld8b 69blcbf2 5f489fcc 98137254 

7cf41dOO 8ef0bcal 926f934b 735e090b 3b251eb3 3a36f82e d9b29cf4 cb944188 

fa0ele38 dd778f7d Ic9d987b 28dl32df b9731fa4 f4b41693 5be49de3 0516af35 

78581f2f 13f561c0 66336194 leab249a 4bcl23f8 dl5cd711 a956albf 20fe6eb7 

8aea2373 361da042 6c79a530 c3bblde0 c99722ef lfde39ac 2b00a0a8 ee7c800a 

08bc2264 f89f4eff e627ac2f 0531fb55 4f6d21d7 4c590a70 adfaa390 bdfbb3d6 

8e46215c abl87d23 68d5a71f 5ebec081 cd3b20cO 82dbe4cd 2faca287 73795d6b 

Ocl0204b 659a939e f29bbelO 88243624 429927a7 eb576dd3 aOOea5eO Iaf5d475 

83b2272c 0cl61a80 6521al6f f9bOa722 C0cf26b0 25d5836e 2258a4f7 d4773ac8 

01e4263b c294f43d ef7fa870 3f3a4197 46352588 7652b0b2 a4a2a7cf 87f00914 

871e2503 9113c7el 618da340 64b57a43 c463249f b8d05eOf 26f4a6d8 4972e7a9 

05482414 5f91295c dbe39a6f 920facc6 59712b46 a54ba295 bbe6a901 54e91b33 

985a2bcd 420ad5c6 7ec9ad8e b7ac6864 db272a51 6bc94c28 39b0a816 9a6bf58e 

Ia0c2ada 8c883b7b f497a491 71268edl 5ddd2969 384e7ff4 bf4aab2e c9ecc652 

9cf629e2 df0f08a7 7a65afal 2aa9b505 df8b287e f6cc9149 3dlcaa39 076e28ef 

Iea028f5 118de61a e02bb6ae fc3343a0 50292fl9 9f401857 b2bead5e 6ee2alfl 

91022f92 78016f04 7791a9dl 8da7d2a6 d27f2eOe 51c2f6ea 30e8ac49 a0604f4c 

13542e85 b68381b9 fdcfaOce 4b2d3413 54852d36 0245c536 b612af71 f3e77c90 

95ae2dbd e504b265 733dabfe 10a20fc7 d6d32c21 ccc72b8b 3444ae66 3d65922d 

17f82caa 2b865cd8 8913d291 a6589902 6eal3284 39723cl9 8c36b0c3 c8d085bf 

af8a320f de334b4a 4919b44c 2b95f6e8 ecf73393 f7fOd2a4 0e60bld4 06526b02 

2ddc3318 10bla5f7 c347bd53 edlfl05d 6a0d30ab a477el78 889ab2ec 55d558de 

ab263020 4336962b 4db5b663 b6902b89 e85b31bc 6af50fc5 0accb3fb 9b57b663 

29703137 8db47896 d7fbaf6c 600add2c 67f936db 037986db 856eb49c f2db3f7d 
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a6d23650 e438fl88 4041b013 119e4c2a e5af37cc cdfb6866 0738b58b 3c59dlc0 

24843747 2abalf35 calfb90c d714aa9f 635534f4 9e7c5bba 81c2b6b3 6fdee21c 

a27e347f 793d2ce9 44edb23c 8c9b914b el0335e3 50feb507 0394b7a4 alScOcal 

20283568 b7bfc254 fe838bl3 7a2147ce 7cll3a3a 4d65499d 9e86b87d bcc7f03b 

bd3a3abl aa243ece 5ba9bcf2 5f82836c fe473b2d 83e7a720 Icd0b96a 72451e86 

3f6c3ba6 64a6d073 dlf7b5ed 990865d9 78bd3815 d06094fc 9a2aba52 21c22d5a 

b996389e 3721e3af 5f05bedd c2875eOd faeb3902 Iee27a41 187cbb45 ef40c3e7 

3bc03989 f9a30dl2 C54ba7d2 141da8a8 75493e65 776ef35f 97debc22 86cc4af9 

b4623eee 902f840c 52flb8ad 658939ae f71f3f72 b9eclde2 1588bd35 484ea444 

3S343ff9 5ead6abl d8afblb2 a303dflb 71e53c4a ea6b2e3e 9372beOd lbc99798 

b0ce3ccl Od2a596d 565dba82 f88ce4cf f3b33d5d 24e9c083 1124bfla d54b7925 
32983dd6 C3a8b7d0 

CMACCK, M) : 

K = b3120ffd b2cf6af4 e73eaf2e f4ebec69 

Mien = 16512 

M = 296f393c 5c000000 00000000 00000000 01010101 01010101 e0958045 f3a0bba4 

63968346 fOa3b8a7 c02a018a 66407652 26b987c9 1366cbfO 83570016 cf836fbc 

61C08251 3621561a 427c009d 28c2986f ac6786d6 d56c2d45 05ad0326 9c04dc60 

673a8169 6da665c6 c48603a5 7b45ab33 22158566 86631691 87fb0239 528632dd 

656c8076 a3248b7b 46d002b2 b5c74586 b85b9c69 58796034 08590556 3b0abbc3 

6ac68719 caa80265 c97205d5 dc4bcc90 2f6l8396 296d7132 8aOf0449 f5885576 

68988606 042a6cd8 4b2404c2 12c9222d a5bf8a89 6f679787 Ocf50771 a60f66a2 

66628536 57addf04 cdd607fa 4146llfl 2b4d81b9 b468ac53 86a30666 688d881f 

6C348421 992f31b9 4f88066d 8fccff4c 9123b896 42527ad6 13bl09bf 75167485 

fl268bf8 84b4cd23 d29a0934 925703d6 34098f77 67flb674 9l6708a8 bb949a38 

73708a6f 4a362396 50cc0823 5cd56d6b b6578668 al7b58cl 171dOb90 6813a964 

f58a89d7 19bll042 d6360blb Of52d6b7 30a58d58 faf46315 954bOa87 26914759 

77dc88cO d733f6ff 54600aOc cld0300a aa6b9457 2c6695bO Ia690d60 4fldc647 

f8768fa7 b6bf776l dbc20d6b a85cb914 3d518b28 5dfa04b6 98bfOcf7 819f20fa 

7a2886bO 703d995c 59940c7c 66d657a9 b70f8237 9b706203 l6450fcf d2181326 

fcd28d88 23baaa80 df660f44 35596475 39fd8907 C0ffd9d7 9cl306d8 Ic9afd9b 

76848c9f 6d38443d 5d380653 fbdb8ac8 c3d3f068 76054fl2 2461107d 692f6a09 

c6f6923a 188d53af 654alOf6 06669d5a 03d996b5 fbc820f8 a637116a 27ad04b4 

44a0932d d60fbdl2 671cll6l c06c7367 89879faa 3d42c64d 20cdl252 742a3768 

c25a9015 858886C6 6l6612d9 936b403b 0775949a 66cdfd99 a29bl345 baa8d9d5 

400C9102 4bOa6073 63b013c6 5d69a686 9d3b8d95 b0570b3c 2d391422 d32450cb 

cfa69665 2286696d 6Cl214a9 34652798 Oa81926a Clc39a3a af6fl535 Ida6b676 

4df89772 6c0407dO 664415b6 fa67c925 80df9bf5 07497c8f 2995160d 46218daa 

cb02944a bf83340c 68b6l686 a960faf9 062d90c5 5cc6475b abc3171a 80a36317 
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4954955d VlOldabl 6ae81791 67e21444 b443a9ea aa7c91de 36dll8c3 9d389f8d 

d4469a84 6c9a262b f7fal848 7a79e8de 11699e0b 8fdf557c b48719d4 53ba7130 

56109b93 a218c896 75acl95f b4fb0663 9b379714 4955b3c9 327dlaec 003d42ec 

d0ea98ab fl9ffb4a f3561a67 e77c35bf 15c59c24 12da881d b02blbfb cebfacSl 

52bc99bc 3fldl5f7 71001b70 29fedb02 8f8b852b c4407eb8 3f891c9c a733254f 

ddle9edb 56919ce9 fea21cl7 4072521c 18319a54 b5d4efbe bddfld8b 69blcbf2 

5f489fcc 98137254 7cf41dOO 8ef0bcal 926f934b 735e090b 3b251eb3 3a36f82e 

d9b29cf4 cb944188 fa0ele38 dd778f7d Ic9d987b 28dl32df b9731fa4 f4b41693 

5be49de3 0516af35 78581f2f 13f561c0 66336194 leab249a 4bcl23f8 dl5cd711 

a956albf 20fe6eb7 8aea2373 361da042 6c79a530 c3bblde0 c99722ef lfde39ac 

2bOOaOa8 ee7c800a 08bc2264 f89f4eff e627ac2f 0531fb55 4f6d21d7 4c590a70 

adfaa390 bdfbb3d6 8e46215c abl87d23 68d5a71f 5ebec081 cd3b20cO 82dbe4cd 

2faca287 73795d6b Ocl0204b 659a939e f29bbelO 88243624 429927a7 eb576dd3 

a00ea5e0 Iaf5d475 83b2272c 0cl61a80 6521al6f f9bOa722 cOcf26bO 25d5836e 

2258a4f7 d4773ac8 01e4263b c294f43d ef7fa870 3f3a4197 46352588 7652bOb2 

a4a2a7cf 87f00914 871e2503 9113c7el 618da340 64b57a43 c463249f b8d05eOf 

26f4a6d8 4972e7a9 05482414 5f91295c dbe39a6f 920facc6 59712b46 a54ba295 

bbe6a901 54e91b33 985a2bcd 420ad5c6 7ec9ad8e b7ac6864 db272a51 6bc94c28 

39bOa816 9a6bf58e Ia0c2ada 8c883b7b f497a491 71268edl 5ddd2969 384e7ff4 

bf4aab2e c9ecc652 9cf629e2 df0f08a7 7a65afal 2aa9b505 df8b287e f6cc9149 

3dlcaa39 076e28ef Iea028f5 118de61a e02bb6ae fc3343a0 50292fl9 9f401857 

b2bead5e 6ee2alfl 91022f92 78016f04 7791a9dl 8da7d2a6 d27f2eOe 51c2f6ea 

30e8ac49 a0604f4c 13542e85 b68381b9 fdcfaOce 4b2d3413 54852d36 0245c536 

b612af71 f3e77c90 95ae2dbd e504b265 733dabfe 10a20fc7 d6d32c21 ccc72b8b 

3444ae66 3d65922d 17f82caa 2b865cd8 8913d291 a6589902 6eal3284 39723cl9 

8c36b0c3 c8d085bf af8a320f de334b4a 4919b44c 2b95f6e8 ecf73393 f7fOd2a4 

Oe60bld4 06526b02 2ddc3318 10bla5f7 c347bd53 edlfl05d 6a0d30ab a477el78 

889ab2ec 55d558de ab263020 4336962b 4db5b663 b6902b89 e85b31bc 6af50fc5 

0accb3fb 9b57b663 29703137 8db47896 d7fbaf6c 600add2c 67f936db 037986db 

856eb49c f2db3f7d a6d23650 e438fl88 4041b013 119e4c2a e5af37cc cdfb6866 

0738b58b 3c59dlcO 24843747 2abalf35 calfb90c d714aa9f 635534f4 9e7c5bba 

81c2b6b3 6fdee21c a27e347f 793d2ce9 44edb23c 8c9b914b el0335e3 50feb507 

0394b7a4 al5cOcal 20283568 b7bfc254 fe838bl3 7a2147ce 7cll3a3a 4d65499d 

9e86b87d bcc7f03b bd3a3abl aa243ece 5ba9bcf2 5f82836c fe473b2d 83e7a720 

Icd0b96a 72451e86 3f6c3ba6 64a6d073 dlf7b5ed 990865d9 78bd3815 d06094fc 

9a2aba52 21c22d5a b996389e 3721e3af 5f05bedd c2875eOd faeb3902 Iee27a41 

187cbb45 ef40c3e7 3bc03989 f9a30dl2 C54ba7d2 141da8a8 75493e65 776ef35f 

97debc22 86cc4af9 b4623eee 902f840c 52flb8ad 658939ae f71f3f72 b9eclde2 

1588bd35 484ea444 36343ff9 5ead6abl d8afblb2 a303dflb 71e53c4a ea6b2e3e 

9372beOd lbc99798 b0ce3ccl Od2a596d 565dba82 f88ce4cf f3b33d5d 24e9c083 
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1124bfla d54b7925 32983dd6 C3a8b7d0 

Subkey Generation: 

L = 2cS45dcd 72114961 d8b9c8S4 7aac2c5b 

Kl = 58c8bb9a e42292c3 bl7390c8 f55858b6 

K2 = bl917735 C8452587 62e72191 eab0bl6c 



MAC Generation: 

n = 129 



Mn* 

Mn 

CO 

Ml 

CI 

M2 

C2 

MS 

C3 

iyi4 

C4 
MS 
C5 
MS 
C6 

iyi7 

C7 
MS 
C8 

iyi9 

C9 

MIO 

CIO 

Mil 

Cll 

M12 

C12 

M13 

C13 

M14 



1124bfla d54b7925 32983dd6 C3a8b7d0 
49ec0480 3169ebe6 83ebadle 36f0ef66 
00000000 00000000 00000000 00000000 
296f393c BcOOOOOO 00000000 00000000 
2cl74eee b856df54 a2e3ce41 116181e0 
01010101 01010101 60958045 f3a0bba4 
7a923db9 b053f844 9e706b27 378aeae0 
63968346 fOa3b8a7 c02a018a 66407652 
59d306bc 86b2314c 74f63a04 la248463 
26b987c9 1366cbfO 83570016 cf836fbc 
78db898b 6396784c 34f86dbd 67a747c5 
61C08251 3621561a 427c009d 28c2986f 
7C296481 44ac6afa 3aca8a4a 7208C699 
ac6786d6 d56c2d45 05ad0326 9c04dc60 
7220fd63 3a769298 C9406349 6ad867d3 
673a8169 6da665c6 c48603a5 7b45ab33 
46663f66 c6529a3b 2a7aa97c 06280443 
22158566 86631691 87fb0239 528632dd 
79803306 ad490c46 3d971205 dc99a211 
656c8076 a3248b7b 46d002b2 b5c74586 
4d74c6c4 f07795ab f6127db4 529dfb57 
b85b9c69 58796034 08590556 3b0abbc3 
a66b9dl6 93820f49 d9c5f96l 760cb686 
6ac68719 caa80265 c97205d5 dc4bcc90 
8f95155b d32ad9a3 4636905d 7ba48066 
2f6l8396 296d7132 8aOf0449 f5885576 
6fl20bfO 66f4c66f a5c67815 65133712 
68988606 042a6cd8 4b2404c2 12c9222d 
db745006 895db74a 6f3b3b87 25087f2b 
a5bf8a89 6f679787 Ocf50771 a60f66a2 
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C14 
M15 
C15 
MIS 
C16 
M17 
C17 
MIS 
C18 
iyil9 
C19 
M2 
C20 
M21 
C21 
iyi22 
C22 
M23 
C23 
iyi24 
C24 
iyi2 5 
C2 5 
iyi2 6 
C2 6 
M27 
C2 7 
M2 8 
C2 8 
M2 9 
C2 9 
M30 
C30 
iyi31 
C31 
M32 
C32 
iyi33 
C33 
iyi34 



f5879dl7 7cOddf7d 5772993a cl37aeab 
ee628536 57addf04 cdde07fa 414ellfl 
bl8a88al bceb93eO a4b7ae95 4479bbfe 
2b4d81b9 b4e8ac53 8ea30666 688d881f 
7d75c4a5 e87bff2f 07471eb4 46fcdb73 
SC348421 992f31b9 4f8806ed 8fccff4c 
b3456ccb e8f3e8d7 33568c84 f89d2145 
9123b896 42527ad6 13bl09bf 75167485 
b5363e85 edabc25d bdla400d 5952742e 
fl268bf8 84b4cd23 d29a0934 925703d6 
55abealb 574ea033 45df9cdl 46flc8e9 
34098f77 67flbe74 91e708a8 bb949a38 
8efc00fd 5d245efc de807875 cd46423d 
73708aef 4a36239e 50cc0823 5cd5ed6b 
aa07abd7 b26d40bO 53945cfa 6aafab45 
be578668 al7b58cl 171dOb90 e813a9e4 
4739c2bb 17ae5960 7ac250e2 c4cl72fa 
f58a89d7 19bll042 d6360blb Of52deb7 
eda48d2b 146feccf Ilc45d3b 2aac4c37 
30a58d58 faf46315 954bOa87 26914759 
4dbbb4e3 9e344d41 d05ca472 50186527 
77dc88cO d733feff 54600aOc cld0300a 
ecda3d93 5776d708 42c9c5da 9a09dbe3 
aaeb9457 2c6e95bO Iae90de0 4fldce47 
58a010aa f0149da7 5dfe9049 4676b663 
f87e8fa7 bebf77el dbc20d6b a85cb914 
d611b8cb bb9fb2ac f82aa88b fd6aab42 
3d518b28 5dfa04b6 98bfOcf7 819f20fa 
a23131a6 d7352c69 e9790a6b 26b0292a 
7a288ebO 703d995c 59940c7c 66de57a9 
9026eOdd c60dc7fe 3ff024e4 5c853be8 
b70f8237 9b70e203 le450fcf d2181326 
af09e79e 54d8c2el 85b08dl2 d638d687 
fcd28d88 23baaa80 df6eOf44 35596475 
f7bc7632 8bll6b03 f5dlfd78 3f4d866d 
39fd8907 C0ffd9d7 9cl30ed8 Ic9afd9b 
Oc2a4710 a2362alf 7967fd45 Ia7dl88d 
7e848c9f ed38443d 5d380e53 fbdb8ac8 
df3fc64e ff5998be 926a71d8 7836cf38 
C3d3f068 76054fl2 2461107d e92fea09 
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C34 
MS 5 
C35 
M36 
C36 
iyi37 
C37 
M38 
C38 
iyi39 
C39 
M4 
C40 
M41 
C41 
Mi2 
C42 
iyi43 
C43 
iyi44 
C44 
iyi4 5 
C4 5 
iyi4 6 
C4 6 
iyi4 7 
C4 7 
iyi4 8 
C48 
M4 9 
C4 9 
M50 
C50 
M51 
C51 
M52 
C52 
iyi53 
C53 
iyi54 



11133bc0 6cdef5b2 0ba5cfl2 b293ea83 
c6f6923a 188d53af e54alOf6 Oe6e9d5a 
fe95113c C42ac4c4 bd53dfcb 41d01fla 
03d996b5 fbc820f8 a637116a 27ad04b4 
fbd5a26b 824d7a62 bdcad592 Oef8d4c8 
44a0932d d60fbdl2 671cllel cOec73e7 
e75a94c8 e5b631b8 6e0fll53 f88b87aa 
89879faa 3d42c64d 20cdl252 742a3768 
773a8452 8fb77154 baaa0445 d517de8f 
c25a9015 85888ece ele612d9 936b403b 
b53b90fO 6dce6530 593171f8 42eb5ab7 
0775949a 66cdfd99 a29bl345 baa8d9d5 
2d211e99 76cad436 d37bb281 74fd9aaf 
400C9102 4bOa6073 63b013ce 5de9ae86 
71f3983e 65f0af4d 028cl308 6488del2 
9d3b8d95 b0570b3c 2d391422 d32450cb 
0d292597 f79f9c95 f213724a 55e54437 
cfae9665 2286e96d ecl214a9 34652798 
9b3ba456 072cdaa2 5bc5dae7 ab5e5c3S 
Oa8192ea clc39a3a af6fl535 Ida6be76 
0a3b8e65 Obf406a9 267783fl 69979a3e 
4df89772 ec0407dO 6e4415be fae7c925 
6a6cb8da bfaca611 7b7fl996 b83d4c92 
80df9bf5 07497c8f 2995160d 4e218daa 
Sed66263 70b356c4 bea4e69b fa281190 
cb02944a bf83340c e8bel686 a960faf9 
S5cf4cda 156b2025 b5b43852 022b0211 
0e2d90c5 5cc6475b abc3171a 80a36317 
96cffOa9 6e209fd5 065c9f34 eOedc899 
4954955d 7101dabl 6ae81791 67e21444 
61158848 8fb6al2b a2al55bc fa279420 
b443a9ea aa7c91de 36dll8c3 9d389f8d 
79al892a 63751231 f45163bb cb8a7729 
d4469a84 6c9a262b f7fal848 7a79e8de 
25C71838 32d36692 22379a7b a086716c 
11699eOb 8fdf557c b48719d4 53ba7130 
466dbaf4 10f27161 202bd3e2 ce7fc5f3 
56109b93 a218c896 75acl95f b4fb0663 
adcb04f6 86696807 38756fa3 7a350ccc 
9b379714 4955b3c9 327dlaec 003d42ec 
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C54 
M55 
C55 
iyi56 
C56 
MS? 
CSV 
MSS 
CBS 
M59 
C59 
M60 
C60 
MSI 
C61 
iyi62 
C62 
M63 
C63 
iyi64 
C64 
MSS 
C65 
M66 
C66 
MS? 
C67 
M68 
C68 
M69 
C69 
MVO 
C70 
M71 
C71 
iyi72 
C72 
iyi73 
C73 
iyi74 



802a2d59 0b3a457a f449ba39 f8bad584 
dOea98ab fl9ffb4a f3561a67 e77c35bf 
b6bbd86d 5e708389 dl8413f9 ddd9a92a 
15c59c24 12da881d b02blbfb cebfacSl 
ff010e37 Oadl420e df6a5276 81b9f685 
52bc99bc 3fldl5f7 71001b70 29fedb02 
a7afl52e bOcOdc25 d96c9792 672c098e 
8f8b852b c4407eb8 3f891c9c a733254f 
957bc801 eaabe60c 27193122 a94cccb8 
ddle9edb 56919ce9 fea21cl7 4072521c 
3b6d3712 3ea45568 15a4c417 3f903fc3 
18319a54 b5d4efbe bddfld8b 69blcbf2 
656e7869 42ef502b f5838dc4 44a89253 
5f489fcc 98137254 7cf41dOO 8ef0bcal 
934b5a02 5051d909 a9d84ab2 547853c6 
926f934b 735e090b 3b251eb3 3a36f82e 
b667b4da 06f5670f c014bb27 09e6el8c 
d9b29cf4 cb944188 fa0ele38 dd778f7d 
88033dbl 446aaalO a348ddaa d7d80dl6 
Ic9d987b 28dl32df b9731fa4 f4b41693 
52d29028 818fae29 dad8clfb 124dl73f 
5be49de3 0516af35 78581f2f 13f561c0 
b6131b03 2cc9c6ae 96051b5d 68aa7659 
66336194 leab249a 4bcl23f8 dl5cd711 
58fbdb68 61d57ded 89977624 977ce584 
a956albf 20fe6eb7 8aea2373 361da042 
b9929b5e 371aOfb6 357c864d 4ea36d30 
6c79a530 c3bblde0 c99722ef lfde39ac 
198a06eb 2c013cab eadb6627 d555e3a6 
2bOOaOa8 ee7c800a 08bc2264 f89f4eff 
dlfOa42a b3045545 8e69a513 14825bfc 
e627ac2f 0531fb55 4f6d21d7 4c590a70 
6b8clbla 03286dde f4ecf569 66f264dO 
adfaa390 bdfbb3d6 8e46215c abl87d23 
082felf5 61373b7b 048b92ed 3b36cld5 
68d5a71f 5ebec081 cd3b20cO 82dbe4cd 
cd304dc4 682e63df 49b7da3b Ie780f3a 
2faca287 73795d6b Ocl0204b 659a939e 
596f4ba2 4a20bblO a9fa3124 6a7488b9 
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